[systemd-devel] DOSing the TPM to leak the rootfs encryption key
Hello all, This is spawned from another recent thread on this list, with the subject "Is tpm2-measure-pcr really an additional security?", started by Yann Diorcet. There's some confusion of what scenario exactly is being discussed in that thread, and in an attempt to clarify I think I came up with my own scenario that I think might be similarly vulnerable. So, I'm making this thread so that we can a clean slate for the discussion of my scenario. Presuming a system like this: - We've got a Linux desktop system - We have two dm-verity protected /usr partitions - We have one encrypted rootfs - We're using systemd-repart to create the rootfs on first boot - The rootfs is automatically unlocked by the initrd, at boot, using the TPM. We're using systemd-pcrlock with a PCR 11 signature - We're making use of systemd-pcrphase, and the rootfs is unlockable _only_ during `enter-initrd`. Once we hit `leave-initrd`, the rootfs is no longer unlockable. This means that the rootfs is only unlockable in the initrd. Here's a potential attack: - Attacker makes a clone of the real rootfs, then marks the partition as empty on the real disk. Attacker puts the disk back into the machine, and boots. - The initrd measures the `enter-initrd` pcrphase - systemd-repart notices that there's no rootfs, and starts creating one. This (in my experience) takes up to a couple of seconds, so it should be relatively feasible to time the attack. Especially if the attacker can see systemd's status output - Meanwhile, the attacker starts DOSing the TPM (i.e. by physically interrupting the TPM's LPC bus) - systemd-repart finishes, and so the initrd boots into the newly-created rootfs - initrd tries to measure the `leave-initrd` pcrphase, or the new rootfs's volume key. Both fail, due to the DOS on the TPM. - The system boots to the new rootfs - Attacker goes through initial-setup, creating a new administrator user for themself. Then they log in, open a terminal, and run `run0`. They type in the password they just set up. The attacker is now at a root shell. - Attacker stops DOSing the TPM - Since the TPM never received the measurements for `leave-initrd`, or the new rootfs's volume key, it is still in the same state as it was in the initrd. - Attacker asks the TPM to unlock the real rootfs - The PCRs are all in the correct state. - The TPM gives the attacker the real rootfs's encryption key. - Attacker gained access to the real rootfs's data - Attacker cleans up all traces of their presence by putting back the real rootfs into its old partition What's protecting against this, if anything? In theory, this should all be detectable. The pcrphase measurements should fail if the TPM fails to reply that it has handled the command, and also pcrphase should probably _read back_ the PCRs and make sure they're at the expected value. Unfortunately, I don't think we actually care at the moment if these measurements fail - they can fail and we'll keep booting. Detecting the situation and causing boot to fail, as described above, would force the attacker to not only DOS the TPM but actually completely MITM it. Is this possible? Is this something that parameter encryption defends against? This attack isn't specific to the assumptions I've made at the start. For example: instead of relying on systemd-repart to create the rootfs on first boot and then going through the legitimate first-boot setup process, an attacker can simply bring their own maliciously-crafted rootfs that boots straight to a root shell. systemd's security model allows an attacker to completely replace the rootfs with a maliciously-crafted one. PS: We should probably be locking the rootfs down to the initial state of PCR 15 too. Since we can assume that PCR 15 must be zeroed out before we unlock the rootfs, we can actually check that. This adds an extra layer of protection: the rootfs can only be unlocked if it's the first rootfs being unlocked. But still: this doesn't defend against the DOS scenario I describe here, since the attack completely bypasses the measurement into PCR 15 Best, Adrian
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
Le 10/03/2025 à 17:27, Adrian Vovk a écrit : Hello, On Mon, Mar 10, 2025, 12:06 Mikko Rapeli 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
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
10.03.2025 18:16, 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 - 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 You do not really need anything of that sort. It will not be possible to unlock using TPM anyway. You do need that initrd is configured to fall back to the interactive passphrase. - The attacker unlocks their malicious rootfs, and then the system continues booting. The attacker now gains control of the system via the root shell. - 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 Again - no physical intervention is needed. - 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? Sort of. OP described the case of the LUKS container in the initrd, but I guess the same is also possible after switch to root. Depending on the initrd and the exact root container setup. 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 This is not needed. - 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. You can bind root to the PCR15 value *before* initrd and make sure initrd will update PCR15 after unlocking root. In this case PCR15 state will be different with the fake root and automatic unlock of the real root is not possible. You can use the service suggested by Alberto that prevents leaving initrd if PCR15 is different. It is possible to prohibit interactive unlock for root container, but that will effectively lock you out if anything happens with TPM. But there are so many possibilities to configure that this discussion needs at least one real life example that demonstrates that this attack is even possible. 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) Best, Adrian On Mon, Mar 10, 2025, 05:23 Yann Diorcet wrote: Hi, Sorry for my english, i'm not english native. Le lun. 10 mars 2025 à 10:04, Lennart Poettering a écrit : On Sa, 08.03.25 19:52, Diorcet Yann (diorcet.y...@gmail.com) wrote: Hello, 61;7802;1c> I'm in the process of using SecureBoot, TPM2.0 and LUKS2 to protect an industrial embedded computer. I have a chain of trust in the UEFI (own secure boot keys/certificates), signed grub2, all files used by grub2 signed including kernel and initramfs, and successfully automatically unlocked LUKS partitions using TPM2.0 using PCR7. The main concern remaining is to be sure to chroot on the "good" root partition (and not a malicious one allowing to decrypt using TPM the "good" partition). pcrphase ensures that "good" root partition can only be unlocked in the good phase (after enter-initrd for example), this is an additional security. tpm2-measure-pcr provides a way to only decrypt other partitions after the "good" root partition: Using for example 7+11+15 But in the case of multiple partitions unlocked by the initrd, I can't figure why an attacker couldn't succeed to : - Clone the original disk (notably ESP) - Replace root partition by a malicious one - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition from the "good" root partition - Boot the machine - The initrd will try unlocks the malicious partition as root. As the TPM token will not work, the attacker will use the password of his malicious LUKS Disable the password prompt via "headless" crypttab option. Thanks for this tip (Not sure if I follow what the issue is supposed to be, i.e. not sure what "try unlocks" is supposed to mean or what "the second" refers to. Just guessing here). There's a TODO list item somewhere to provide more finegrained conrol of which mechanisms are allowed to allow a disk, and conversely to measure the actual mechanism used. But until then simply disable interactivity fully. (note that fido2, tpm2, pkcs11 unlocking needs to b
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On Mon, Mar 10, 2025 at 11:03 AM aplanas wrote:
>
> On 2025-03-08 18:52, Diorcet Yann wrote:
>
> > But in the case of multiple partitions unlocked by the initrd, I can't
> > figure why an attacker couldn't succeed to :
> >
> > - Clone the original disk (notably ESP)
> >
> > - Replace root partition by a malicious one
> >
> > - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition
> > from the "good" root partition
>
> This is done by "systemd-pcrfs[-root]". The attacker needs to have
> access to the system (as a normal user to use something like lsblk)
>
The attacker will have a different root filesystem that allows anything.
> tpm2-measure-pcr take the LUKS2 volume key (cryptsetup luksDump
> --dump-master-key), and this requires the effective unlock of the device
> (via TPM2 or passphrase)
>
> > - Boot the machine
> >
> > - The initrd will try unlocks the malicious partition as root. As the
> > TPM token will not work, the attacker will use the password of his
> > malicious LUKS
> >
> > - Make the update of the PCR due to the measuring of the malicious
> > partition fails
>
> As commented, using tpm2-measure-pcr, PCR15 will be extended with
> HMAC("cryptsetup:$name:$uuid", vk), and vk cannot be impersonated.
>
The catch here is that you need to bind your *root* to the PCR15 too.
I.e. you need both
systemd-cryptenroll --tpm2-pcrs=...+15:sha256=0x0 ... /dev/your-root
and /etc/crypttab in initrd
cr_root /dev/your-root - tpm2-measure-pcr,...
Otherwise the described attack looks possible (probably, depending on
the other PCRs to which root is bound).
> > - Initrd will try to unlock the second partition, which is the "good"
> > root partition, and it will succeed, allowing the attacker to finally
> > access all data from the partition.
>
> Yes, this partition can be unlocked using a policy that uses PCR0..9 for
> TPM2 (without PIN). But not necessarily means that the attacker has any
> access yet, at least not while we are in the initrd.
>
See above. Attacker has already substituted the root, so /if/ this
unlocks succeeds, the attacker has access to the system.
Another way to mitigate this is to additionally bind to the PCRs that
measure bootloader state like PCR5. As long as the fake root has a
different GUID it should prevent automatic unlocking. Not sure how
UEFI firmware will respond to two completely identical disks.
> With measured boot, the previous stage measure something of the next
> stage before delegating. The initrd needs to measure something from the
> device to continue the chain of trust. IIRC in the image-based proposal
> that was the dm-verity root key. If dm-verity is not used, then
> something else needs to be measured. The volume key seems a good
> replacement.
>
> > The main point here is to "Make the update of the PCR due to the
> > measuring of the malicious partition fails".
>
> I think that there is a more simple model, that was described in a nice
> blog post some months ago. The idea is to never leave the initrd if the
> expected value of PCR15 is not meet.
>
Yes, but the point is that you need to arrange for that additionally.
> In this model PCR15 does not participate in the unseal of any secret.
> Instead you need to mark the encrypted partitions as tpm2-measure-pcr
> that are unlocked early in the initrd (root, swap, and the ones with
> x-initrd.attach).
>
> Maybe using a generator, we need to order how systemd-cryptsetup will
> access those devices. This is optional, but will simplify a lot how to
> make predictions for PCR15.
>
> The last step is to have a service in the initrd that is executed after
> systemd-cryptsetup@.service, but before the switch root, it will compare
> the current PCR15 value with the expected one, and if it fails it will
> halt the system.
>
Well, with e.g. dracut an attacker still can break early, before your
script runs, and manually invoke systemd-cryptsetup. This will not
even require any faking of LUKS UUID or partition GUID. And it will
not require any fake root. The protection must belong to the LUKS
partition itself. It must be bound to the PCRs which allow detection
of the altered command line among other things. Binding root to PCR7
most certainly is *not* enough.
> With something like this an attacker cannot replace any of the disk that
> belong to the OS without being detected. This would require the
> alteration of initrd in the UKI or on the ESP, that is covered by the
> measured boot policy.
>
> There is some code here:
>
> * A generator that order the PCR15 extensions
>
> https://github.com/openSUSE/sdbootutil/blob/main/measure-pcr-generator.sh
>
> * A predictor for PCR15
>https://github.com/openSUSE/sdbootutil/blob/main/sdbootutil#L2210
>
> * A validator service that stop the boot process if the expected value
> did not match
>(also validate the signature of the file that contains the prediction)
>
> https://github.com/openSUSE/sdbootutil/blob/main/measure-pcr-validator.sh
>
> * (Only for n
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On 2025-03-10 08:41, Andrei Borzenkov wrote:
On Mon, Mar 10, 2025 at 11:03 AM aplanas wrote:
On 2025-03-08 18:52, Diorcet Yann wrote:
> - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition
> from the "good" root partition
This is done by "systemd-pcrfs[-root]". The attacker needs to have
access to the system (as a normal user to use something like lsblk)
The attacker will have a different root filesystem that allows
anything.
Right. But my point was that to impersonate the original root they have
to know those values and for that they need access to the system.
I do not know in the OP case, but in some other situations if the user
has enough access to know those values the system can be already be
considered compromised.
tpm2-measure-pcr take the LUKS2 volume key (cryptsetup luksDump
--dump-master-key), and this requires the effective unlock of the
device
(via TPM2 or passphrase)
> - Boot the machine
>
> - The initrd will try unlocks the malicious partition as root. As the
> TPM token will not work, the attacker will use the password of his
> malicious LUKS
>
> - Make the update of the PCR due to the measuring of the malicious
> partition fails
As commented, using tpm2-measure-pcr, PCR15 will be extended with
HMAC("cryptsetup:$name:$uuid", vk), and vk cannot be impersonated.
The catch here is that you need to bind your *root* to the PCR15 too.
I.e. you need both
systemd-cryptenroll --tpm2-pcrs=...+15:sha256=0x0 ... /dev/your-root
and /etc/crypttab in initrd
cr_root /dev/your-root - tpm2-measure-pcr,...
Otherwise the described attack looks possible (probably, depending on
the other PCRs to which root is bound).
That does not make any sense to me ...
For systemd-cryptsetup to measure PCR15 it need to read the vk, and to
read the vk the volume needs to be already unlocked. PCR15 cannot
participate in the unlock policy.
> - Initrd will try to unlock the second partition, which is the "good"
> root partition, and it will succeed, allowing the attacker to finally
> access all data from the partition.
Yes, this partition can be unlocked using a policy that uses PCR0..9
for
TPM2 (without PIN). But not necessarily means that the attacker has
any
access yet, at least not while we are in the initrd.
See above. Attacker has already substituted the root, so /if/ this
unlocks succeeds, the attacker has access to the system.
And I agree on that, but I also wrote that for that to be true the
initrd needs complete the switch root (and delegate the execution the
init process to the compromised device).
My point is that there is a lapse of time where the compromised device
and the real root are open (bad thing), but the control is still in the
trusted initrd (good thing). In this brief moment the attacker has no
control of the system yet.
Another way to mitigate this is to additionally bind to the PCRs that
measure bootloader state like PCR5. As long as the fake root has a
different GUID it should prevent automatic unlocking. Not sure how
UEFI firmware will respond to two completely identical disks.
I thought about PCR 5 too, but IIUC the measured information is easy to
replicate.
I think that there is a more simple model, that was described in a
nice
blog post some months ago. The idea is to never leave the initrd if
the
expected value of PCR15 is not meet.
Yes, but the point is that you need to arrange for that additionally.
That I do not understand.
The last step is to have a service in the initrd that is executed
after
systemd-cryptsetup@.service, but before the switch root, it will
compare
the current PCR15 value with the expected one, and if it fails it will
halt the system.
Well, with e.g. dracut an attacker still can break early, before your
script runs, and manually invoke systemd-cryptsetup.
For that you need to change the cmdline, that was measured and part of
the policy that open the device.
The protection must belong to the LUKS
partition itself. It must be bound to the PCRs which allow detection
of the altered command line among other things. Binding root to PCR7
most certainly is *not* enough.
The current implementation of tpm2-measure-pcr is based on extending
PCR15 with the LUKS2 volume key, and the key point is that to extract
this volume key you already need to open the device. That is the point
that I think you are missing.
But I see that maybe there are other alternatives, like reading the
LUKS2 raw header with the keyslots and encrypted vk. That measure could
participate in the policy, and even if it can be replicated, I do not
see how can be used, but this is not how tpm2-measure-pcr works.
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On Sa, 08.03.25 19:52, Diorcet Yann (diorcet.y...@gmail.com) wrote: > Hello, 61;7802;1c> > I'm in the process of using SecureBoot, TPM2.0 and LUKS2 to protect an > industrial embedded computer. > > I have a chain of trust in the UEFI (own secure boot keys/certificates), > signed grub2, all files used by grub2 signed including kernel and > initramfs, and successfully automatically unlocked LUKS partitions using > TPM2.0 using PCR7. > > The main concern remaining is to be sure to chroot on the "good" root > partition (and not a malicious one allowing to decrypt using TPM the "good" > partition). > > pcrphase ensures that "good" root partition can only be unlocked in the good > phase (after enter-initrd for example), this is an additional security. > > tpm2-measure-pcr provides a way to only decrypt other partitions after the > "good" root partition: Using for example 7+11+15 > > > But in the case of multiple partitions unlocked by the initrd, I can't > figure why an attacker couldn't succeed to : > > - Clone the original disk (notably ESP) > > - Replace root partition by a malicious one > > - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition from > the "good" root partition > > - Boot the machine > > - The initrd will try unlocks the malicious partition as root. As the TPM > token will not work, the attacker will use the password of his malicious > LUKS Disable the password prompt via "headless" crypttab option. (Not sure if I follow what the issue is supposed to be, i.e. not sure what "try unlocks" is supposed to mean or what "the second" refers to. Just guessing here). There's a TODO list item somewhere to provide more finegrained conrol of which mechanisms are allowed to allow a disk, and conversely to measure the actual mechanism used. But until then simply disable interactivity fully. (note that fido2, tpm2, pkcs11 unlocking needs to be enabled manually, it's only passphrase/recovery key unlock which is on by default, and which you have to turn off via headless) > - Make the update of the PCR due to the measuring of the malicious partition > fails hmm, i really cannot parse this? (not the rest either...?) Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
Hi, Sorry for my english, i'm not english native. Le lun. 10 mars 2025 à 10:04, Lennart Poettering a écrit : > > On Sa, 08.03.25 19:52, Diorcet Yann (diorcet.y...@gmail.com) wrote: > > > Hello, > 61;7802;1c> > > I'm in the process of using SecureBoot, TPM2.0 and LUKS2 to protect an > > industrial embedded computer. > > > > I have a chain of trust in the UEFI (own secure boot keys/certificates), > > signed grub2, all files used by grub2 signed including kernel and > > initramfs, and successfully automatically unlocked LUKS partitions using > > TPM2.0 using PCR7. > > > > The main concern remaining is to be sure to chroot on the "good" root > > partition (and not a malicious one allowing to decrypt using TPM the "good" > > partition). > > > > pcrphase ensures that "good" root partition can only be unlocked in the good > > phase (after enter-initrd for example), this is an additional security. > > > > tpm2-measure-pcr provides a way to only decrypt other partitions after the > > "good" root partition: Using for example 7+11+15 > > > > > > But in the case of multiple partitions unlocked by the initrd, I can't > > figure why an attacker couldn't succeed to : > > > > - Clone the original disk (notably ESP) > > > > - Replace root partition by a malicious one > > > > - Fake the second (using UUID/PARTLABEL/...) but using LUKS partition from > > the "good" root partition > > > > - Boot the machine > > > > - The initrd will try unlocks the malicious partition as root. As the TPM > > token will not work, the attacker will use the password of his malicious > > LUKS > > Disable the password prompt via "headless" crypttab option. Thanks for this tip > > (Not sure if I follow what the issue is supposed to be, i.e. not sure > what "try unlocks" is supposed to mean or what "the second" refers > to. Just guessing here). > > There's a TODO list item somewhere to provide more finegrained conrol > of which mechanisms are allowed to allow a disk, and conversely to > measure the actual mechanism used. But until then simply disable > interactivity fully. > > (note that fido2, tpm2, pkcs11 unlocking needs to be enabled manually, > it's only passphrase/recovery key unlock which is on by default, and > which you have to turn off via headless) > > > - Make the update of the PCR due to the measuring of the malicious partition > > fails > > hmm, i really cannot parse this? (not the rest either...?) If an attacker jams the communication with the TPM (discret one for example) during the measuring phase of the first partition (which in my example is the malicious one), the PCR will not be updated. Allowing the second partition to be unlocked as it would be unlocked in normal situtation: as the first unlocked partition. If you don't add counter measure at the end of initrd in order to fail this trick (as alplanas explained), you will chroot on the malicious partition with the the good root partition unlocked and mounted as the second partition. > > Lennart > > -- > Lennart Poettering, Berlin Yann
Re: [systemd-devel] Is tpm2-measure-pcr really an additional security?
On 2025-03-10 18:25, Diorcet Yann wrote: Le 10/03/2025 à 17:27, Adrian Vovk a écrit : 2) Just before opening the var LUKS: PCR15=0 or something predictable cryptsetup is used to open var and update PCR15 thanks to tpm2-measure-pcr=yes. but in this case /dev/sda1 is replaced with the original /dev/sda1 partition. I think that you mean that /dev/sda2 (/var) is replaced with the original /dev/sda1 (rootfs), so mounting the original root in /var, right? PCR15=hash1 3) initrd makes the mount of the fs, makes multiple measurements (notably on PCR11 with leave-initrd) then chroots and executes malicious init. Is PCR15 checked against a pre-calculated value saved in the signed initrd before leaving initrd? If it's not the case, then when executing the init from the chrooted malicious partition, the original /dev/sda1 LUKS will be opened and mounted as var. You need a service in the initrd to do that. systemd AFAIK is not currently providing one, but the plumbing is there to bring your own.
Re: [systemd-devel] DOSing the TPM to leak the rootfs encryption key
On Mon, Mar 10, 2025 at 09:10:59PM +, aplanas wrote: > On 2025-03-10 19:04, Adrian Vovk wrote: > > > Presuming a system like this: > > - We've got a Linux desktop system > > - We have two dm-verity protected /usr partitions > > - We have one encrypted rootfs > > - We're using systemd-repart to create the rootfs on first boot > > - The rootfs is automatically unlocked by the initrd, at boot, using the > > TPM. We're using systemd-pcrlock with a PCR 11 signature > > - We're making use of systemd-pcrphase, and the rootfs is unlockable > > _only_ > > during `enter-initrd`. Once we hit `leave-initrd`, the rootfs is no > > longer > > unlockable. This means that the rootfs is only unlockable in the initrd. > > If this a good idea in general? This makes impossible to update the NVIndex > policy automatically via the recovery PIN. You need to ask the user for the > PIN after each new make-policy. > > > Here's a potential attack: > > It is very similar to the original one published some months ago[1], and the > one described in the other thread. All three boils to the same topic, the > measure boot is stopping in the initrd and we need a way to authenticate the > device before delegating the execution. Just continue the measure boot one > extra step. > > [1] https://oddlama.org/blog/bypassing-disk-encryption-with-tpm2-unlock/ > > The solution presented there will resolve the three instances of this > attack. You just need to measure the vk of each device that is in the > initrd's /etc/crypttab in an ordered way and halt the system from the initrd > if the value is not the expected one. systemd could do that, but if not it > is not hard to implement [2] > > [2] > https://github.com/openSUSE/sdbootutil/blob/main/measure-pcr-validator.service > > > - Meanwhile, the attacker starts DOSing the TPM (i.e. by physically > > interrupting the TPM's LPC bus) > > You would need a bit more than that. The tcti commands needs to be parsed > and make some assumptions about the encrypted payload, to determine what > commands to filer out. > > [...] > > Detecting the situation and causing boot to fail, as described above, > > would > > force the attacker to not only DOS the TPM but actually completely MITM > > it. > > Is this possible? Is this something that parameter encryption defends > > against? > > Yes, they are for that[3]. > > [3] > https://trustedcomputinggroup.org/wp-content/uploads/TCG_CPU_TPM_Bus_Protection_Guidance_Passive_Attack_Mitigation_8May23-3.pdf How does parameter encryption establish the shared secret between the CPU and the TPM? Ideally the secure connection would be established at CPU reset using a secret fused into the CPU, and a hash of that secret would be measured by the TPM itself. Unfortunately, this is not a feature TPMs have. Mobile secure elements solve this by having the SoC and the secure element permanently paired to each other, allowing them to mutually authenticate and establish an encrypted and authenticated connection. I don't know any way to do this with a TPM. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
