August 9th, 2024

Researchers discover potentially catastrophic exploit present in AMD chips

Researchers have found a serious vulnerability in AMD processors, affecting chips since 2006, allowing deep firmware access. AMD is developing patches, with risks primarily for corporations and government entities.

Read original articleLink Icon
Researchers discover potentially catastrophic exploit present in AMD chips

Researchers from IOActive have identified a significant vulnerability in AMD processors, termed the "Sinkclose" flaw, which has existed for over a decade. This security issue resides in the firmware of AMD chips, potentially allowing malware to gain deep access to a computer's memory and execute code in the System Management Mode, a highly privileged area of the processor. The flaw affects nearly all AMD chips dating back to at least 2006. While the exploit is serious, it is unlikely to impact average users, as attackers would need extensive access to the system to exploit it fully. However, the risk is heightened for corporations and government entities, as the malicious code could remain undetected even after an operating system reinstall. AMD has acknowledged the vulnerability and is working on mitigation strategies for affected products, although the company emphasizes that exploiting this flaw requires overcoming significant security measures. IOActive has refrained from releasing proof-of-concept code while AMD develops patches, stressing the urgency of addressing the issue to maintain overall system security.

- A significant vulnerability in AMD processors has been discovered, affecting nearly all chips since 2006.

- The exploit allows deep access to a computer's firmware, posing risks primarily to corporations and government entities.

- AMD is working on mitigation strategies and has acknowledged the seriousness of the flaw.

- Exploiting the vulnerability requires extensive access, making it less likely to affect average users.

- IOActive has chosen not to publish proof-of-concept code while AMD develops necessary patches.

Link Icon 14 comments
By @somat - 5 months
Whats with the doom laden tone of the article? I could have written "hackers figure out how to open the management engine, no longer need you be a serf on your own CPU" and it would be just as accurate.
By @bastawhiz - 5 months
Description of the CVE:

> Improper validation in a model specific register (MSR) could allow a malicious program with ring0 access to modify SMM configuration while SMI lock is enabled, potentially leading to arbitrary code execution.

By @pizlonator - 5 months
Weird how first the article downplays this because you supposedly need so much privilege to exploit this bug and then they point out that you need to have kernel privileges.

So that’s pretty bad. Kernel exploits aren’t that hard to find and it looks like this bug gives a path from kernel exploit to exploit persistence, with the only way to get rid of the persisted exploit is to throw away the CPU.

If I’m understand it right then, like, yikes!

By @PedroBatista - 5 months
It would not be a Summer time end of the week without the obligatory catastrophic flaw or snafu to keep everyone busy..

It looks bad but this phrase looks even worse for AMD: "No fix planned"[1].

Finally internalizing themselves as the winner and starting to pull an Intel?

[1] - https://www.amd.com/en/resources/product-security/bulletin/a...

By @echoangle - 5 months
Can someone explain how the persistence can work as described here? I thought the CPU microcode was stored in the BIOS, and the CPU itself doesn’t have a persistent memory. Wouldn’t I have to exchange the Motherboard and not the CPU if I was infected by this? Or just reflash the BIOS, assuming the corrupted BIOS doesn’t somehow prevent BIOS flashing?

Edit after looking it up (leaving this comment in case someone else has the same question): Apparently microcode is in fact stored in the CPU itself and it does have permanent storage. The BIOS is only used for updating this internal memory and doesn’t transfer the microcode on every boot. I still wonder if the microcode patches are somehow validated/signed though, otherwise everyone with a kernel exploit could issue update commands to the BIOS with malicious microcode content?

By @jl6 - 5 months
Where would exploit code persist? In the BIOS EEPROM? Are Dual-BIOS motherboards such as from Gigabyte (which can re-flash the BIOS from a read-only copy on a second chip) a viable recovery option for a system which has been infested using this attack?
By @farawayea - 5 months
They don't want to fix this for Ryzen 3000 desktop CPUs. I guess they're not getting money from me for at least 5 years.

How is a compromised AMD CPU better than Intel's CPUs which get damaged due to oxidation and high voltage?

By @yencabulator - 5 months
Video of the talk is up at https://youtu.be/7Wp5D-a0XgE about 2h3min into the live stream.
By @commercialnix - 5 months
We need heavy-handed laws mandating that any firmware included with hardware sold must be accompanied by source code, documentation to interfaces, and can be flashed by any person in legal possession/ownership of the hardware. And, that any cryptographic keys for such are not "fused in" so they can be changed with appropriate physical access (and optionally sealed with tamper-evident material).

There's no valid reason to not have this law. Any "intellectual property" excuses aren't going to fly, everyone already knows they're bullshit.

edited: slightly clarified legal possession

By @mike256 - 5 months
That's actually good news. It means I can access data which is encrypted in a secure part of memory which I am forced to have but don't want.
By @nightowl_games - 5 months
Less is more. We need less surface area to attack. The most secure system is one that does not have any input.
By @dtx1 - 5 months
Oh did they find the NSA Backdoor or are all hardware firmwares just leaking like a sieve?
By @jmole - 5 months
I’ve always kept the dedicated BMC network port locked down out of paranoia, but this seems to be an exploit that a rogue BMC or BIOS could use to access the host networking stack.