3 ms·

The exploit has everything to do with the TPM. It sounds like you don't understand why that is. The TPM measures everything that you feed it. The firmware feed

The exploit has everything to do with the TPM. It sounds like you don't understand why that is. The TPM measures everything that you feed it. The firmware feeds it whatever binaries it boots, and those binaries may in turn feed it other data (configuration, chainloaded kernels, initrd, etc). Just booting a live disk on a TPM-encrypted computer won't be sufficient to access the data, as the loaded binaries/kernel arguments/etc will be different, so the TPM measurements will b e different. As such, it won't unlock. The problem here is that the TPM doesn't measure things running in Linux (at least, not by default), so it doesn't know the difference between "expected initrd booting correctly" and "expected initrd being exploited".

vlovich123 3y ago
I was ignorant about the argument here, so I went back and read the article. I’m going to have to side with the other guy. The TPM is not involved nor does it work quite as you’re describing (at least in the configuration outlined). What the article is describing is a normally headless setup (eg server farm) where the TPM owns responsibility for providing the password for unlocking the encrypted root volume. This has nothing to do with software integrity which I think is what you’re describing. The specific bug here is that the TPM agent and the interactive agent are running at the same time for systemd and the exploit is to get the interactive agent to trigger enough failures before the TPM agent does that you interrupt the normal boot flow. At which point systemd drops you into a recovery shell, you ask the TPM to unlock, and you can now mount the disk manually without having entered any password. The only reason Windows doesn’t have a problem is they ask the TPM to unlock long before they ever allow for any interactivity. Measuring “initrd is behaving correctly” is not in the purview of a TPM except for “is the executable I’m loading legit” as part of a chain of trust (which again, while valuable and good and important to discuss, is completely separate from this article).

vlovich123 3y ago

I was ignorant about the argument here, so I went back and read the article. I’m going to have to side with the other guy. The TPM is not involved nor does it work quite as you’re describing (at least in the configuration outlined). What the article is describing is a normally headless setup (eg server farm) where the TPM owns responsibility for providing the password for unlocking the encrypted root volume. This has nothing to do with software integrity which I think is what you’re describing. The specific bug here is that the TPM agent and the interactive agent are running at the same time for systemd and the exploit is to get the interactive agent to trigger enough failures before the TPM agent does that you interrupt the normal boot flow. At which point systemd drops you into a recovery shell, you ask the TPM to unlock, and you can now mount the disk manually without having entered any password. The only reason Windows doesn’t have a problem is they ask the TPM to unlock long before they ever allow for any interactivity. Measuring “initrd is behaving correctly” is not in the purview of a TPM except for “is the executable I’m loading legit” as part of a chain of trust (which again, while valuable and good and important to discuss, is completely separate from this article).