3 ms·

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 pro

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).
ajross 3y ago
> this attack is particularly alarming because it circumvents a TPM, FWIW, I think this phrasing is a little confusing. The TPM wasn't compromised at all. What happened is that the attack trips systemd into a fatal error path where it gives up and just drops the user at a root shell (!!!). From there you can simply command the TPM to do its thing and cough up the key, and it will trust you because you're the presumably-authenticated boot firmware.
jiveturkey 3y ago
In addition to the inaccuracies others have mentioned, the iPhone secure enclave is not a TPM. Saying it is isn't a simplification, it's muddying the waters.
- chatmasta 3y ago
  Can you explain the difference a bit more, and why it's more than just splitting hairs? Is it because TPM is a specific standard for implementation of a secure co-processor, whereas Secure Enclave is part of a larger SoC (T2), which while it could be considered an implementation of a secure co-processor, is distinct from the TPM standard? In researching this comment I learned that the T2 chip actually runs its own operating system (bridgeOS), so I can see why you'd call it an oversimplification (or muddying the waters) to equate it to a TPM.
  - als0 3y ago
    The TPM is an TCG standard (also ISO/IEC 11889), and specifies commands that support a lot of use cases. The Secure Enclave from Apple is something simpler and more restrictive, that is tailored only for Apple's use cases.
    - jiveturkey 3y ago
      simpler? hardly. high level overview: https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web https://support.apple.com/guide/security/secure-enclave-sec5... low level overiew: https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De... AFAIK, and it's hard to find the info since I don't have it handy, so I don't want to devote the searching time, but bringing it back on-topic, all disk i/o has to go through the secure enclave for encryption and decryption. i believe this is better documented on mac than iphone. the data storage is always encrypted since T2. If filevault is enabled, then the user's password gets mixed in with the T2 hardware keys. Because those keys can never leave T2, all disk i/o necessarily goes through it. This is vastly different than how TPM operates.
alasarmas 3y ago
It seems to me that the FBI can break into iPhones now, but they want to pretend that they can’t. The FBI strategy appears to be to fake the lack of capability to break in now, in order to be able to claim that there is a crisis and get law or legal precedent in place to allow much broader access, against potentially much better future technological challenges to break-in. I believe that, from a technical perspective, my argument is supported by this article [0] that I found posted on the ACLU website. This was a reaction to the FBI’s highly-publicized case against Apple in 2015 where the FBI, I believe, pretended that they could not break into the iPhone that had belonged to one of the shooters in the December 2015 San Bernardino attack. The article I have linked describes a specific technical workaround for avoiding permanent deletion of data, namely, avoiding deletion in “Effaceable Storage” of a key that encrypts some filesystem data. This may or may not continue to be relevant today. A pop-up on an Apple page explaining iPhone privacy [1] specifically states that Effaceable Storage “doesn’t provide protection if an attacker has physical possession of a device”, but I don’t claim to actually understand the security implications of the statements made on that page. 0. https://www.aclu.org/news/privacy-technology/one-fbis-major-claims-iphone-case-fraudulent https://www.aclu.org/news/privacy-technology/one-fbis-major-... 1. https://support.apple.com/guide/security/data-protection-sece8608431d/web https://support.apple.com/guide/security/data-protection-sec...

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).

ajross 3y ago

> this attack is particularly alarming because it circumvents a TPM, FWIW, I think this phrasing is a little confusing. The TPM wasn't compromised at all. What happened is that the attack trips systemd into a fatal error path where it gives up and just drops the user at a root shell (!!!). From there you can simply command the TPM to do its thing and cough up the key, and it will trust you because you're the presumably-authenticated boot firmware.

jiveturkey 3y ago

In addition to the inaccuracies others have mentioned, the iPhone secure enclave is not a TPM. Saying it is isn't a simplification, it's muddying the waters.

chatmasta 3y ago
Can you explain the difference a bit more, and why it's more than just splitting hairs? Is it because TPM is a specific standard for implementation of a secure co-processor, whereas Secure Enclave is part of a larger SoC (T2), which while it could be considered an implementation of a secure co-processor, is distinct from the TPM standard? In researching this comment I learned that the T2 chip actually runs its own operating system (bridgeOS), so I can see why you'd call it an oversimplification (or muddying the waters) to equate it to a TPM.
- als0 3y ago
  The TPM is an TCG standard (also ISO/IEC 11889), and specifies commands that support a lot of use cases. The Secure Enclave from Apple is something simpler and more restrictive, that is tailored only for Apple's use cases.
  - jiveturkey 3y ago
    simpler? hardly. high level overview: https://support.apple.com/guide/security/secure-enclave-sec59b0b31ff/web https://support.apple.com/guide/security/secure-enclave-sec5... low level overiew: https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-Demystifying-The-Secure-Enclave-Processor.pdf https://www.blackhat.com/docs/us-16/materials/us-16-Mandt-De... AFAIK, and it's hard to find the info since I don't have it handy, so I don't want to devote the searching time, but bringing it back on-topic, all disk i/o has to go through the secure enclave for encryption and decryption. i believe this is better documented on mac than iphone. the data storage is always encrypted since T2. If filevault is enabled, then the user's password gets mixed in with the T2 hardware keys. Because those keys can never leave T2, all disk i/o necessarily goes through it. This is vastly different than how TPM operates.

alasarmas 3y ago

It seems to me that the FBI can break into iPhones now, but they want to pretend that they can’t. The FBI strategy appears to be to fake the lack of capability to break in now, in order to be able to claim that there is a crisis and get law or legal precedent in place to allow much broader access, against potentially much better future technological challenges to break-in. I believe that, from a technical perspective, my argument is supported by this article [0] that I found posted on the ACLU website. This was a reaction to the FBI’s highly-publicized case against Apple in 2015 where the FBI, I believe, pretended that they could not break into the iPhone that had belonged to one of the shooters in the December 2015 San Bernardino attack. The article I have linked describes a specific technical workaround for avoiding permanent deletion of data, namely, avoiding deletion in “Effaceable Storage” of a key that encrypts some filesystem data. This may or may not continue to be relevant today. A pop-up on an Apple page explaining iPhone privacy [1] specifically states that Effaceable Storage “doesn’t provide protection if an attacker has physical possession of a device”, but I don’t claim to actually understand the security implications of the statements made on that page. 0. https://www.aclu.org/news/privacy-technology/one-fbis-major-claims-iphone-case-fraudulent https://www.aclu.org/news/privacy-technology/one-fbis-major-... 1. https://support.apple.com/guide/security/data-protection-sece8608431d/web https://support.apple.com/guide/security/data-protection-sec...