12 ms·

Meh, it's an interesting exploit for sure (the USB key simulating Enter key being pressed every 15ms is cute). But IMO unless you run a very hardened setup, pr

Meh, it's an interesting exploit for sure (the USB key simulating Enter key being pressed every 15ms is cute). But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. In a hardened setup you lock down the emergency initrd shell - either it's not allowed at all, or it uses a password which hopefully is a little more secure against an attacker pressing the Enter key a lot ;) The real eye opener for me is what Ventoy can do. You can plug it into a computer with Secure Boot enabled, and it will give you a nice user-friendly way to just ... completely and trivially bypass Secure Boot protection. Yes, really: https://www.ventoy.net/en/doc_secure.html https://www.ventoy.net/en/doc_secure.html It won't work for every mobo/firmware combo. It worked first try for me on some used Lenovo ThinkCentre M710q I bought on eBay, though. Even with the latest June 2023 BIOS installed. Ventoy does this by using a known exploit in a GRUB shim that is signed with the official Microsoft certs (that ones that are embedded in virtually every mobo sold with Secure Boot support), in order to pop the KeyEnroll UEFI application and then enroll its own keys in there. Or something like that. Sure, M$ put out a windows update ages ago that updates the DBX to prevent this particular signed shim with known vulnerabilities: https://support.microsoft.com/en-us/topic/kb5012170-security-update-for-secure-boot-dbx-72ff5eed-25b4-47c7-be28-c42bd211bb15 https://support.microsoft.com/en-us/topic/kb5012170-security... ... but who knows how many more are out there in the wild? Once you've pwned Secure Boot (and I'm making the case here that any script kiddy can do this on a vast majority of commonly available/used mobos, let alone a professional cybercrime gang/local LE division or, god-forbid, 3 letter agency), then you can simply pop in your favourite (Arch, obviously) Linux live USB and `cryptsetup open` your favourite encrypted drive in seconds. For unattended machines, especially if you've already bothered to stick a Clevis in there, you really ought to blend your TPM ping with a SSS (min 2) one-two combo-punch of a Tang pin. But again, if the attacker is literally sitting at your desk typing in your computer connected to your trusted networks and such, you're always gonna be pretty screwed.

chatmasta 3y ago
You raise a valid point, but this attack is particularly alarming because it circumvents a TPM, which is a hardware module that was specifically designed to protect against evil-maid class of attacks, e.g. every iPhone after the 5S uses its Secure Enclave (a TPM) to enforce time delays between passcode attempts [0], so that a physical attacker can't brute force the passcode. (Incidentally, the attack described in the OP is reminiscent of some early attacks against the iPhone that used an HID device to circumvent passcode rate limiting.) IMO, the continuing difficulty that the FBI has breaking into seized iPhones is proof that it's possible to ship a device with hardware that is sufficiently secure to mitigate against any physical exfiltration of data, but this is probably only possible because of the fully vertical integration of Apple hardware, firmware, and software (and even then - it's still a cat and mouse game, bugs will eventually be exposed, etc.). For open source software that runs on any arbitrary assemblage of hardware components, I suspect it's nigh impossible to achieve this same level of physical security. [0] https://support.apple.com/en-gb/guide/security/sec20230a10d/1/web/1#:~:text=How%20escalating%20time%20delays https://support.apple.com/en-gb/guide/security/sec20230a10d/...
- hedora 3y ago
  It doesn't really bypass the TPM though. These machines configure the TPM without a pin so they can boot + decrypt the drive in an unattended mode. I'd trust this setup to prevent drives that were removed from servers from being decrypted (like for recycling), but it's basically useless against any other class of attack. It's good to see publicized exploits of it though; that way people can link to this blog post if a pointy-haired-boss tries to misapply this class of disk encryption.
- gameoverhumans 3y ago
  No, this explot has nothing to do with the TPM. The problem is tricking the initrd in giving you a shell, at which point you are able to run arbitrary "unprivileged" code (i.e your shell commands) and tell the TPM to do whatever you want. Gaining a shell using the technique in this article is functionally equivalent to the bypass Secure Boot -> boot live Linux scenario I described in parent comment. The article notes that Windows "avoids" this issue by measuring into PCR11 as early as possible, but it stands to reason that any kind of exploit that is found in the windows boot flow that happens before this moment would be the same issue as the described Clevis+initrd issue.
  - reanimus 3y ago
    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).
hollerith 3y ago
>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?
- jsmith99 3y ago
  The code that displays the password prompt and unlocks the disk could be replaced by a modified copy as it isn't encrypted. TPM would protect against that though.
- michaelt 3y ago
  If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot. The evil maid attack on an encrypted disk with a passphrase is that the attacker installs a hardware keylogger, then comes back the next day and snatches your laptop, which the keylogger tells them the password for. If you've got highly sensitive chassis intrusion detection that wipes your secrets at the drop of a hat, the evil maid triggers it in a way that looks like a false alarm, and uses a hidden camera in the ceiling to watch your recovery procedure. And if you would never be so naive as to have a recovery procedure, the attack is to laugh their ass off because you needed that laptop to give the conference talk / client demo you came to this city for, and it also had your boarding pass on it, and now you're fired and you're stranded.
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
  - Aurornis 3y ago
    > If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot. That's a weird dismissal. This attack is a big deal because it provides a workaround to full desk encryption. I have no idea why so many people in this thread are trying to pretend it's not a big deal. This is a big deal. Full disk encryption is supposed to make sure your data is safe if the laptop is stolen. This attack makes your data vulnerable if your laptop is stolen.
jsmith99 3y ago
That just defeats secure boot, it doesn't defeat TPM backed drive encryption, which only releases the key if the OS is unchanged, otherwise you could just defeat it by booting a different signed OS.
- gameoverhumans 3y ago
  That depends on which PCRs you bind your TPM-backend encryption key to. See this list: https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/ https://uapi-group.org/specifications/specs/linux_tpm_pcr_re... As an example, Arch Wiki encourages you to bind to PCR 0+7: https://wiki.archlinux.org/title/Trusted_Platform_Module#systemd-cryptenroll https://wiki.archlinux.org/title/Trusted_Platform_Module#sys... ... both of those are firmware-level PCRs, not OS ones.
  - tomatocracy 3y ago
    PCRs 0+7 might not be sufficient if you don't have an up to date dbx (revocation list) - older versions of shim won't (I think) extend into PCR 7 enough information on what they chainload. This means a malicious bootloader could fake the correct PCR extensions. Updating dbx to a version which revokes versions of shim with this issue would fix this I think, as would including PCR 4 in the list bound to, to make doubly sure that the version of shim is new enough not to present a risk.
wkat4242 3y ago
I don't agree. What Ventoy does is simply enabling the user to do what they have the rights to do already in a more user-friendly way. If the user doesn't have BIOS admin access this won't work. If they do they can just enroll the new key through the menu.
deleted 3y ago
[deleted]

chatmasta 3y ago

You raise a valid point, but this attack is particularly alarming because it circumvents a TPM, which is a hardware module that was specifically designed to protect against evil-maid class of attacks, e.g. every iPhone after the 5S uses its Secure Enclave (a TPM) to enforce time delays between passcode attempts [0], so that a physical attacker can't brute force the passcode. (Incidentally, the attack described in the OP is reminiscent of some early attacks against the iPhone that used an HID device to circumvent passcode rate limiting.) IMO, the continuing difficulty that the FBI has breaking into seized iPhones is proof that it's possible to ship a device with hardware that is sufficiently secure to mitigate against any physical exfiltration of data, but this is probably only possible because of the fully vertical integration of Apple hardware, firmware, and software (and even then - it's still a cat and mouse game, bugs will eventually be exposed, etc.). For open source software that runs on any arbitrary assemblage of hardware components, I suspect it's nigh impossible to achieve this same level of physical security. [0] https://support.apple.com/en-gb/guide/security/sec20230a10d/1/web/1#:~:text=How%20escalating%20time%20delays https://support.apple.com/en-gb/guide/security/sec20230a10d/...

hedora 3y ago
It doesn't really bypass the TPM though. These machines configure the TPM without a pin so they can boot + decrypt the drive in an unattended mode. I'd trust this setup to prevent drives that were removed from servers from being decrypted (like for recycling), but it's basically useless against any other class of attack. It's good to see publicized exploits of it though; that way people can link to this blog post if a pointy-haired-boss tries to misapply this class of disk encryption.
gameoverhumans 3y ago
No, this explot has nothing to do with the TPM. The problem is tricking the initrd in giving you a shell, at which point you are able to run arbitrary "unprivileged" code (i.e your shell commands) and tell the TPM to do whatever you want. Gaining a shell using the technique in this article is functionally equivalent to the bypass Secure Boot -> boot live Linux scenario I described in parent comment. The article notes that Windows "avoids" this issue by measuring into PCR11 as early as possible, but it stands to reason that any kind of exploit that is found in the windows boot flow that happens before this moment would be the same issue as the described Clevis+initrd issue.
- reanimus 3y ago
  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).

hollerith 3y ago

>But IMO unless you run a very hardened setup, protecting against evil maid attacks (wherein the attacker has physical access to your machine in its entirety) is really hard, and possibly always will be. Can you describe an evil maid attack on an encrypted disk that gets unlocked by the user's entering a passphrase?

jsmith99 3y ago
The code that displays the password prompt and unlocks the disk could be replaced by a modified copy as it isn't encrypted. TPM would protect against that though.
michaelt 3y ago
If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot. The evil maid attack on an encrypted disk with a passphrase is that the attacker installs a hardware keylogger, then comes back the next day and snatches your laptop, which the keylogger tells them the password for. If you've got highly sensitive chassis intrusion detection that wipes your secrets at the drop of a hat, the evil maid triggers it in a way that looks like a false alarm, and uses a hidden camera in the ceiling to watch your recovery procedure. And if you would never be so naive as to have a recovery procedure, the attack is to laugh their ass off because you needed that laptop to give the conference talk / client demo you came to this city for, and it also had your boarding pass on it, and now you're fired and you're stranded.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- Aurornis 3y ago
  > If you've got a user who can enter a long passphrase, you don't need a TPM, so this TPM bypass is moot. That's a weird dismissal. This attack is a big deal because it provides a workaround to full desk encryption. I have no idea why so many people in this thread are trying to pretend it's not a big deal. This is a big deal. Full disk encryption is supposed to make sure your data is safe if the laptop is stolen. This attack makes your data vulnerable if your laptop is stolen.

jsmith99 3y ago

That just defeats secure boot, it doesn't defeat TPM backed drive encryption, which only releases the key if the OS is unchanged, otherwise you could just defeat it by booting a different signed OS.

gameoverhumans 3y ago
That depends on which PCRs you bind your TPM-backend encryption key to. See this list: https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/ https://uapi-group.org/specifications/specs/linux_tpm_pcr_re... As an example, Arch Wiki encourages you to bind to PCR 0+7: https://wiki.archlinux.org/title/Trusted_Platform_Module#systemd-cryptenroll https://wiki.archlinux.org/title/Trusted_Platform_Module#sys... ... both of those are firmware-level PCRs, not OS ones.
- tomatocracy 3y ago
  PCRs 0+7 might not be sufficient if you don't have an up to date dbx (revocation list) - older versions of shim won't (I think) extend into PCR 7 enough information on what they chainload. This means a malicious bootloader could fake the correct PCR extensions. Updating dbx to a version which revokes versions of shim with this issue would fix this I think, as would including PCR 4 in the list bound to, to make doubly sure that the version of shim is new enough not to present a risk.

wkat4242 3y ago

I don't agree. What Ventoy does is simply enabling the user to do what they have the rights to do already in a more user-friendly way. If the user doesn't have BIOS admin access this won't work. If they do they can just enroll the new key through the menu.

deleted 3y ago

[deleted]