[systemd-devel] DOSing the TPM to leak the rootfs encryption key

[aplanas]

On 2025-03-13 10:10, Andrei Borzenkov wrote:
> On Tue, Mar 11, 2025 at 12:17 AM aplanas <aplanas at suse.de> 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.