Re: Is tpm2-measure-pcr really an additional security?

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Mo, 10.03.25 12:27, Adrian Vovk (adrianvovk@xxxxxxxxx) wrote:

> Well, the TPM is supposed to be secure against hardware debugger access, in
> theory. Ditto with CPUs, and JTAG lockout.
>
> So if there's TOCTOU bugs in our code we need to be robust against them too.
>
> Anyway, I don't think this is a TOCTOU bug. Basically, it seems that we're
> sometimes OK letting communication to the TPM fail. In which case, an
> attacker can cause the communication to fail, and we'll be none the wiser
>
> If device specific encryption key leaks, then the data there can be modified
>
> by the attacker. I too fail to see the bug here.
> >
>
> Right, this is what we're trying to avoid.
>
> Basically, the bug is: an attacker does a DOS on the TPM in such a way that
> systemd boots to the rootfs without measuring the `leave-initrd` pcrphase,
> or the fake rootfs's pcr15. Once in the rootfs, the TPM doesn't know that
> it has left the initrd. And that's game over: the attacker stops DOSing the
> TPM, and extracts the encryption keys for the real rootfs from the TPM.

it is true that we currently do not block continued booting if a
measurement fails.

I figure systemd-pcrextend should start to simply invoke
reboot(RB_HALT_SYSTEM) if a TPM exists but it cannot extend a
PCR. Happy to take a PR for that.

But then again, this isn't perfect either, because being able to issue
the PCR extension is one thing. Actually verifying it had the desired
effect on the right PCR of the right TPM is another. Or in other
words: to be fully correct we would need to get a TPM quote on the
relevant PCR from the TPM, validate it and check that the measurement
is in there. And if not, also reboot.

Note that nothing of this is really a "bug" though, it's just an effect of
designing your trust model to be tighter or more relaxed.

Lennart

--
Lennart Poettering, Berlin