Hello, On Mon, Mar 10, 2025, 12:06 Mikko Rapeli <mikko.rap...@linaro.org> wrote:
> 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. > This is inaccurate. systemd's security model allows for the rootfs to be replaced with a different one. There's no good way to actually prevent that: all partition table metadata is spoofable, including UUIDs and whatnot Of course, if you're using dm-verity on the rootfs, the attacker can only replace the rootfs with a copy of itself. But I don't think this is the case here, since the thread started with the presumption that the attacker can replace the rootfs. To be clear, the partition layout I'm thinking about is: dm-verity protected /usr partitions (A/B copies), and then a separate rootfs partition that exists just to store persistent data (/var, /etc, etc). In this scenario, there's nothing preventing someone from replacing the rootfs partition's contents with anything arbitrary. > - 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. > If you can replace the rootfs (which we've established: you can), then that rootfs can contain whatever you want to gain execution early during boot. It can be as easy as a single symlink in /etc: basic.target.wants/systemd-debug-shell.service 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 point is to disable the TPM enough that systemd gives up trying to measure pcrphases, and moves on. If it continues booting in that case, there's a big problem > - 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. > 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. Best, Adrian
