PCR 8 dependency unreliable

[anedward01]

Using PCR 8 can brick devices and cause them to be unusable until manually recovered. PCR 8 is controlled by the GRUB2 bootloader. Whenever the bootloader updated, devices are bricked on the next reboot.

Additionally, when an EFI stub is booted directly, PCR 8 and 9 are empty as they are populated by GRUB2's boot process.

The best course of action is taking a default empty PCR and manually populating the values using different measures. The measurement should be added as a script to the kernel's boot process.

Using the checksum of db.crt and the EFI kernel's verification detail along with a signature list would be a good start. PCR 12 would be a viable PCR to work with.

[evaporatingtime]

I've noticed that if you don't use PCR8 then the automatic decryption still takes place if you boot into recovery mode at the grub2 menu (this is with Ubuntu 20.04). This leaves the drive decrypted at a prompt with has root privileges and no means of authentication, hence anyone with physical access to the system would be able to trivially defeat the encryption.

[anedward01]

I'll need to verify a couple of things before I can test this. The reason PCR 8 isn't used is an issue that can't be circumvented.

[anedward01]

When you mean the automatic decryption takes place, does it error out then drop the shell, or does it unlock and then drop to the shell? If it errors out, then the only concern would be point 1. Otherwise, if it unlocks in recovery mode, cryptsetup and/or TPM assignment was misconfigured.

1. In the fallback kernel shell, is secret.bin exposed in /usr/local/var/tpm-manager?
   If it is, then this presents a security risk. If not, then the TPM may still be exposed
2. In the fallback kernel, try running /usr/local/bin/passphrase-from-tpm. If it spills the secret, this would mark a legitimate security issue. If not, LUKS could still be secure.
3. Can you provide a copy of PCR 7 when booting from the EFI stub and when booting the regular kernel/fallback kernel?

Finally, the current method to prevent recovery shell from dropping is adding panic=0 to the stub EFI boot parameters. Because it is added through GRUB, however, this doesn't fix the underlying issue of just getting rid of panic=0.

[evaporatingtime]

Otherwise, if it unlocks in recovery mode, cryptsetup and/or TPM assignment was misconfigured.

Yes, it's unlocking in recovery mode so the filesystem is exposed in the root shell.

1. In the fallback kernel shell, is secret.bin exposed in /usr/local/var/tpm-manager?
   If it is, then this presents a security risk. If not, then the TPM may still be exposed
2. In the fallback kernel, try running /usr/local/bin/passphrase-from-tpm. If it spills the secret, this would mark a legitimate security issue. If not, LUKS could still be secure.
3. Can you provide a copy of PCR 7 when booting from the EFI stub and when booting the regular kernel/fallback kernel?

I will try and get these for you, but the PC that I'm able to test all of this on is in the office and it's a bit difficult to get there with the current COVID situation...

Finally, the current method to prevent recovery shell from dropping is adding panic=0 to the stub EFI boot parameters. Because it is added through GRUB, however, this doesn't fix the underlying issue of just getting rid of panic=0.

I wouldn't want to prevent a recovery shell, this is a useful feature. It would be preferable to just ensure that you are required to enter the fallback passphrase when booting like this (i.e. fail to unlock via TPM).

[evaporatingtime]

After some investigations into the computer in question, the problem was that (presumably due to bugs in the UEFI firmware) the EFI stub boot entry created by efibootmgr in setup didn't persist over a reboot. Therefore tpm2PolicyConfig sealed against the GRUB boot entry.

When booting with GRUB, and not the EFI stub, the system is vulnerable to local attacks if not sealed on PCR8.

Perhaps a new issue is required here, because I think this could be partially mitigated by checking the boot order again in tpm2PolicyConfig to make sure it persisted. Otherwise, in my opinion, it would be preferable not to seal the secret.