Re: DOSing the TPM to leak the rootfs encryption key

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2025-03-13 10:10, Andrei Borzenkov wrote:
On Tue, Mar 11, 2025 at 12:17 AM aplanas <aplanas@xxxxxxx> wrote:

[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.

I would reword it. The attack is possible because we are not checking the integrity of the device before we give the control to it.

As commented, destroying the policy would indeed make the recovery of the TPM2 sealed key impossible, but then the daily operation will suffer and the recovery PIN needs to be entered after each update.

You argued that this PIN could be unsealed by a different policy, but then this policy needs to be broken in the new situation, or else the attacker can meet the policy and recover the PIN, that can update the policy that can validate a rogue initrd.

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.

Right, PCR15 will be changed just when the device is unlocked, but again, the problem is that there is no order in PCR15 extension. If you create a policy that adds PCR15 expecting 0x0...0 to unlock root, then this can work, or not. If you have an encrypted swap, then the value of PCR15 is not determined unless you impose an order.

Can you ensure that we never ever enter initrd emergency shell?

Would

[Unit]
OnFailure=systemd-halt.service

or

[Service]
FailureAction=reboot-immediate

prevent that?

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.

That was discussed in a different thread. The session is encrypted, so commands that uses or return private data are encrypting this parameter / return value.

I like the idea behind systemd-verifyfs, but I would not make it dependent of fs attributes, but device one (with the caveat of the extension order). But I agree that separating the policy that unlock the device from the policy that unlock the PIN deserve to be explored.



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux