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

[Mikko Rapeli <mikko.rapeli@xxxxxxxxxx>]

Hi,

On Mon, Mar 10, 2025 at 11:16:25AM -0400, Adrian Vovk wrote:
> Hello,
> 
> Just to see if I understand your concern correctly, I'll try boiling it
> down to its simplest, by cutting out the need for two partitions. Here's
> the scenario:
> 
> - An attacker replaces the real rootfs with a malicious one that just drops
> to a shell. The attacker keeps a copy of the original real rootfs

This should not be possible without breaking encryption keys from the device.
If the rootfs is not encrypted with device specific keys derived from TPM
measurements or dm-verity where root hash has been hard coded into secureboot
signed UKI binary for the kernel, then the setup is not secure to start with.
If dm-verity image has been tampered it will fail signature checks and fail
to mount.

> - The system boots, then tries and fails to decrypt the fake rootfs.
> 
> - The attacker now starts impeding communication between the TPM and the
> CPU. Potentially by physically interposing on the bus and blocking
> communication. Or by glitching the bus so that the data isn't successfully
> measured. Anyway, the attacker somehow makes TPM measurements fail
> 
> - The attacker unlocks their malicious rootfs, and then the system
> continues booting. The attacker now gains control of the system via the
> root shell.

This means that TPM, firmware, kernel or initrd have been compromized at
runtime after their TPM measurements and secureboot signatures have been
verified. A denial of service attack is relatively simple but any code
executions should be grave bugs which need updates to get fixed. An initrd
should have only very limited functionality and no fallback interactive
shells or prompts, or network drivers or daemons.

For example systemd-boot disables kernel command line editing if secureboot
was enabled. Thus with UEFI firmware, signed systemd-boot and kernel and initrd
from a signed UKI binary it is not possible to change the boot behavior trivially.
It may be possible to cut down TPM communication and to make systemd and other
service to wait for longer time but it is simpler to freeze RAM and CPU
state and change the rootfs entry with physical attack via JTAG, if such interfaces
are enabled in HW.

> - The attacker stops impeding the communication between the TPM and the
> CPU. The TPM is still in the same state as it was in the initrd. The
> leave-initrd pcrphase, and the PCR15 measurement of the fake root's volume
> key, are both missing
>
> - The attacker is in control of the system, and the TPM is in the right
> state to unlock the real rootfs. The attacker talks to the TPM to get the
> real rootfs's volume key. Attacker wins
> 
> I think, ultimately, this is the same issue as the one you describe. Do you
> think that's correct?
> 
> Lennart would have a better idea than I do of what mitigations to this
> would look like. But I suspect that:
> 
> - You can't MITM the TPM, since the communication is encrypted
> 
> - Other kinds of attacks cause the OS to know that a measurement failed. So
> perhaps we need to very strict about ensuring that measurements happen.
> i.e. By not letting the TPM disappear at runtime, and making sure that
> measurements always succeed (and if it does, failing to boot or something)

TOCTOU, time of check vs. time of use bugs may exists but they should be
very hard to trigger, e.g. require HW debugger level access.

If device specific encryption key leaks, then the data there can be modified
by the attacker. I too fail to see the bug here.

Cheers,

-Mikko