AMD faulTPM Exploit Targets Zen 2 and Zen 3 Processors

[erek]

More exploits

"

AMD SpokespersonAMD is aware of the research report attacking our firmware trusted platform module which appears to leverage related vulnerabilities previously discussed at ACM CCS 2021. This includes attacks carried out through physical means, typically outside the scope of processor architecture security mitigations. We are continually innovating new hardware-based protections in future products to limit the efficacy of these techniques. Specific to this paper, we are working to understand potential new threats and will update our customers and end-users as needed.

The attack is also public with code available on GitHub."

Source: https://www.techpowerup.com/308124/amd-faultpm-exploit-targets-zen-2-and-zen-3-processors

 

[4saken]

lol, that is a ridiculous exploit.

 

[Gideon]

You can get through Fort Knox if you have physical access and can take however long you like. That's not a exploit, that's just kind of reality. Let me know when they can do it remotely, then it's a issue.

 

[carceri]

While I can see why some people will claim that this is a ridiculous exploit that has no real world implication, I think it is worth mentioning that this is actually a threat model that the TPM is designed to protect against.

Also, the TPM protect BitLocker encryption keys, so extracting those from a stolen system is something that you actually do want to protect against.

 

[Lakados]

While I can see why some people will claim that this is a ridiculous exploit that has no real world implication, I think it is worth mentioning that this is actually a threat model that the TPM is designed to protect against.

Also, the TPM protect BitLocker encryption keys, so extracting those from a stolen system is something that you actually do want to protect against.

Yeah TPM was developed to prevent the “OH Shit!!! I lost my laptop at the airport and now all this confidential stuff has been leaked” scenario.

 

[SmokeRngs]

TPM was a failure before it was ever released. It's a single, common point of failure that can be easily targeted leading to massive security risks. "Hardware" based security will always be a detriment and liability.

 

[jardows]

From the article:

The attack requires several hours of physical access, so remote vulnerabilities are not a problem. Below, you can see the $200 system used for this attack and an illustration of the physical connections necessary.

Fooling someone to give up their password to an "IT technician" is a whole lot easier, faster, and cheaper. There is a reason these sorts of exploits are found by researchers in a lab, rather than by bad actors actually breaking into systems. I'm all for more secure platforms, but the way these things get reported is all FUD.

 

[Bowman15]

The report does not specify if Zen 4 CPUs are vulnerable, and the attack does require physical access to the machine for 'several hours.'

Yawn...

 

[RanceJustice]

While its still noteworthy for edge cases and should be mitigated if possible on existing hardware (possibly already patched for Zen4 ?), the fact that it requires physical, local access, specialized hardware kit (capable of messing with voltage , injection etc), and 30+ minutes of time limit its danger to the average user - this isn't something that even a targeted attack can accomplish online. It seems most likely applicable to something akin to industrial espionage or the like, as even an "evil maid" short term access parameter wouldn't be sufficient.

Though this is still a good time to mention that both Intel ME and AMD PSP are not serving the users by acting as proprietary blackboxes. Atop the (admittedly unverified, but not necessarily unwarranted) concerns over possibility to function as backdoors originally for state-level agencies, "security through obscurity" isn't keeping these "secret" , autonomous parts of the CPU from having vulnerabilities; not this most recent one, nor the older but more dramatic SA-00086 and 112 ! It was after these Intel vulnerabilities debuted that both Intel and AMD for the first time gave users info about and means to control or ostensibly disable some aspects of these subsystems, where previously the undocumented "high assurance platform" mode disabling these feautres was kept exclusive to systems being sold for usage in certain gov't procurement.. Users should have full control over the hardware they purchase , no "blackbox" ARM cores sitting at the lowest level and with access to everything else the computer is doing. The verified ability to disable certain functionality that is unnecessary on the ME and PSP is imperative . I haven't even gotten into the concerns and issues with TPM usage and the plans that many (see Valorent's rootkit level anticheat, attempting to use a TPM 2.0 secret to ban user on the hardware level like their PC was a bloody console!) are putting together for when the feature is prevalent, such as Win11 full compatibility requiring TPM 2.0 . For the moment, those with premium, enthusiast motherboards often have a stand-alone TPM 2.x or newer chip which is swappable, but others may depend solely on the CPU's trusted module or co-processors to store TPM or similar style secret keys.

The potential is that these supposed "security" features are designed to benefit hardware platform, software third parties, and other corporate actors (along with possible state level intelligence and/or cybercrime if such vulnerabilities are exposed) as opposed to the CPU's owners themselves! The sooner that can be resolved the better and while "unofficial" tools such as Coreboot/Libreboot, the work done by System76, and others are a great partial start, continual lobbying of these companies - especially AMD, who has catered to more open spec and software in the past - needs to show them that users care about these issues and they can have an easy PR win by taking a better, user focused path. Though this latest exploit is not something that's going to be vastly popular in the wild, spreading automatically across networks, its still a good time to remind AMD that there could be a better way forward with official solutions to have full control over TPM and PSP for those that have the interest.

 

[Lakados]

While its still noteworthy for edge cases and should be mitigated if possible on existing hardware (possibly already patched for Zen4 ?), the fact that it requires physical, local access, specialized hardware kit (capable of messing with voltage , injection etc), and 30+ minutes of time limit its danger to the average user - this isn't something that even a targeted attack can accomplish online. It seems most likely applicable to something akin to industrial espionage or the like, as even an "evil maid" short term access parameter wouldn't be sufficient.

Though this is still a good time to mention that both Intel ME and AMD PSP are not serving the users by acting as proprietary blackboxes. Atop the (admittedly unverified, but not necessarily unwarranted) concerns over possibility to function as backdoors originally for state-level agencies, "security through obscurity" isn't keeping these "secret" , autonomous parts of the CPU from having vulnerabilities; not this most recent one, nor the older but more dramatic SA-00086 and 112 ! Users should have full control over the hardware they purchase , no "blackbox" ARM cores sitting at the lowest level and with access to everything else the computer is doing. The verified ability to disable certain functionality that is unnecessary on the ME and PSP is imperative . I haven't even gotten into the concerns and issues with TPM usage and the plans that many (see Valorent's rootkit level anticheat, attempting to use a TPM 2.0 secret to ban user on the hardware level like their PC was a bloody console!) are putting together for when the feature is prevalent, such as Win11 full compatibility requiring TPM 2.0 . For the moment, those with premium, enthusiast motherboards often have a stand-alone TPM 2.x or newer chip which is swappable, but others may depend solely on the CPU's trusted module or co-processors to store TPM or similar style secret keys.

The potential is that these supposed "security" features are designed to benefit hardware platform, software third parties, and other corporate actors (along with possible state level intelligence and/or cybercrime if such vulnerabilities are exposed) as opposed to the CPU's owners themselves! The sooner that can be resolved the better and while "unofficial" tools such as Coreboot/Libreboot, the work done by System76, and others are a great partial start, continual lobbying of these companies - especially AMD, who has catered to more open spec and software in the past - needs to show them that users care about these issues and they can have an easy PR win by taking a better, user focused path. Though this latest exploit is not something that's going to be vastly popular in the wild, spreading automatically across networks, its still a good time to remind AMD that there could be a better way forward.

I was once working with a contract for a Lotto corporation and the security they put on laptops was a big deal, their CEOs and upper management were known targets because if you could steal their laptops and such it was a potential payday for somebody. Actually had a case where at a conference somebody dressed as staff went into one of the rooms after to “clean” and made their way out with a half dozen laptops. The frantic calls to get those locked down and remotely wiped was a major issue they were all equipped with cellular models for just that reason, could pop into the MDM and remotely brick them as well as track them to a limited degree.

 

[Brackle]

So yeah you need physical access. I would be more concerned with other things going on if someone physically got into a data center or a business and tried to access a server/PC.

By that time security had LONG failed.....