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

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Di, 11.03.25 13:16, Lennart Poettering (lennart@xxxxxxxxxxxxxx) wrote:

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

I prepped a PR for that now:

https://github.com/systemd/systemd/pull/36705

Turned out to be much simpler than I expected...

Lennart

--
Lennart Poettering, Berlin