Re: DOSing the TPM to leak the rootfs encryption key

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On Tue, Mar 11, 2025 at 12:17 AM aplanas <aplanas@xxxxxxx> wrote:
>
> On 2025-03-10 19:04, Adrian Vovk wrote:
>
> > Presuming a system like this:
> > - We've got a Linux desktop system
> > - We have two dm-verity protected /usr partitions
> > - We have one encrypted rootfs
> > - We're using systemd-repart to create the rootfs on first boot
> > - The rootfs is automatically unlocked by the initrd, at boot, using
> > the
> > TPM. We're using systemd-pcrlock with a PCR 11 signature
> > - We're making use of systemd-pcrphase, and the rootfs is unlockable
> > _only_
> > during `enter-initrd`. Once we hit `leave-initrd`, the rootfs is no
> > longer
> > unlockable. This means that the rootfs is only unlockable in the
> > initrd.
>
> If this a good idea in general? This makes impossible to update the
> NVIndex policy automatically via the recovery PIN.  You need to ask the
> user for the PIN after each new make-policy.
>

Nothing prevents using different policies for NVIndex.

> > Here's a potential attack:
>
> It is very similar to the original one published some months ago[1], and
> the one described in the other thread.  All three boils to the same
> topic, the measure boot is stopping in the initrd and we need a way to
> authenticate the device before delegating the execution.  Just continue
> the measure boot one extra step.
>
> [1] https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/
>

This attack is possible because root is bound to the boot time TPM
state that is not modified after the system is booted. To mitigate
this, the root has to be additionally bound to some run-time state
that only allows unlocking during the specific boot stage. Whether it
is PCR11 for pcrextend or PCR15 for other filesystem or something else
doesn't really matter. But PCR15 looks better - it will be
automatically set as soon as the (fake) root is unlocked, thus
changing run-time state for any subsequent attempt to mount the real
root. The default setup of pcrextend does not help here - we only do
it entering and leaving initrd, so inside initrd there is no state
change after the (fake) root was unlocked. Thus the scenario with
multiple filesystems inside initrd is still vulnerable.

> The solution presented there will resolve the three instances of this
> attack.  You just need to measure the vk of each device that is in the
> initrd's /etc/crypttab in an ordered way and halt the system from the
> initrd if the value is not the expected one. systemd could do that, but
> if not it is not hard to implement [2]
>
> [2]
> https://github.com/openSUSE/sdbootutil/blob/main/measure-pcr-validator.service
>

Can you ensure that we never ever enter initrd emergency shell? This
is yet another vector - let dracut fail the root mount but still
unlock the other LUKS volume.

And if we consider the possibility of spoofing TPM communication - the
values are in clear text and so can be spoofed (as long as it is
technically possible at all). I suppose it can be improved by
encrypting via TPM.