Re: DOSing the TPM to leak the rootfs encryption key

[Andrei Borzenkov <arvidjaar@xxxxxxxxx>]

On Thu, Mar 13, 2025 at 2:06 PM aplanas <aplanas@xxxxxxx> wrote:
>
> 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.
>

I guess it depends on the objectives.

I would like to see a solution that can be enabled by default for an
average non-technical user. Both your solution and upstream PR
effectively lock users out if something goes wrong. This may be
appropriate for a standalone appliance, but for a common desktop
installation I want to prevent automatic decryption, not to block the
user from accessing his system to repair it.

So, I don't really care whether an attacker can enter the fake root or
not. I do care that the attacker will not gain access to the encrypted
content when doing it.

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

Exactly the same consideration applies to your suggested solution.

> > Can you ensure that we never ever enter initrd emergency shell?
>
> Would
>
> [Unit]
> OnFailure=systemd-halt.service
>
> or
>
> [Service]
> FailureAction=reboot-immediate
>
> prevent that?
>

I do not know. Someone intimately familiar with dracut needs to chime in.

But see above. I do not think power off in this case is something that
should be enabled by default.