Researchers discover potentially catastrophic exploit present in AMD chips

[somat]

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.

[mindslight]

Honestly! From a non-corporate perspective this sort of thing is a welcome development. The constructive concern is whether this might enable coreboot/libreboot on newer generation processors, and if not then whether it's ergonomic enough to at least enable widespread neutering of AMD's built-in trojans.

(PS if you're worried about the illegibility of your computer's storage devices and your resulting inability to completely wipe it and reinstall, then that sounds like a problem with your motherboard!)

[bastawhiz]

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.

[AnimalMuppet]

OK, but... if a malicious program has ring0 access, isn't it game over anyway?

[pizlonator]

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!

[mjg59]

SMM shouldn't let you modify any persistent CPU-level state - SMM is slightly magic, but not that magic. It could absolutely allow modification of motherboard-level firmware, but that's repairable given enough enthusiasm.

[dtx1]

It's also unclear wether a virtualized guest can use this exploit. If so, it's a matter of hours until every cloud provider gets infected.

[PedroBatista]

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

[molyss]

I'm not sure if the linked pages was updated recently, if I'm completely misreading it or if you're trolling. There's only one processor family (matisse) that's documented as "no fix planned). All datacenter products already have a fix published, and all non-matisse chips will have a new firmware available by october 2024

[isotypic]

The "No fix planned" is specifically for just the Ryzen 3000 desktop series. While obviously a fix would be better, given the age of this series as well as the need for ring 0 access to exploit the vulnerability, the actual impact from leaving it unfixed on those CPUs will probably be pretty limited.

[sqeaky]

This isn't catastrophic this is clickbait bullshit. The attacker needs ring 0 privileges, this enables someone with kernel level access to right to the firmware. That's not good, but it's not catastrophic either

[echoangle]

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?

[mjg59]

The microcode store in the CPU itself shouldn't be writable (if it were we wouldn't need to load microcode updates from the firmware or the OS on every boot), but there needs to be some microcode on there for the CPU to be able to execute the firmware code that updates the microcode. And yes, microcode is signed (and typically also encrypted). SMM shouldn't have any special level of access to the microcode, any persistence here is likely via the system firmware (which should, as a result, be caught by Platform Secure Boot on platforms where that's enabled)

[trebligdivad]

Yes, probably - but don't forget that the normal user way of 'reflashing the BIOS' is to tell the BIOS to reflash a new image; so in theory (but hard) a malicious BIOS could keep itself in there. If you used JTAG etc to reflash the BIOS externally then yes you could probably clear it out.

[jl6]

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?

[creer]

Persists in BIOS flash most likely - that's the writeable place. Re-flashable if the invaded BIOS even tells you that it's been changed (why would it?). And then if it lets you reflash (why would it). Let you switch to the 2nd BIOS perhaps (why would it?). You might reflash by going straight to the flash memory pins but only if you could tell that you need to - or if you are paranoid enough and have the means.

[farawayea]

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?

[gruez]

>They don't want to fix this for Ryzen 3000 desktop CPUs. [...]

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

From a sibling comment:

>Improper validation in a model specific register (MSR) could allow a malicious program with ring0 access

For the typical desktop scenario, this is a nothingaburger because it's already game over if malicious code can get any sort of access[1]. It might matter more for server providers because their customers can execute arbitrary ring0 code in guest VMs, but it's unclear whether it affects that or not.

Having security bugs isn't great, but in this case having hardware degradation leading to performance loss and/or crashing is much noticeable.

[1] https://xkcd.com/1200/

[wmf]

Original source: https://ioactive.com/event/def-con-talk-amd-sinkclose-univer...

[yencabulator]

Video of the talk is up at https://youtu.be/7Wp5D-a0XgE about 2h3min into the live stream.

[commercialnix]

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

[mike256]

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.

[nightowl_games]

Less is more. We need less surface area to attack. The most secure system is one that does not have any input.

[dtx1]

Oh did they find the NSA Backdoor or are all hardware firmwares just leaking like a sieve?

[kmeisthax]

The "NSA backdoor" is the vulnerabilities we found along the way. It's almost certainly either bad firmware code or bad hardware design. Well, to be clear, SMM is bad hardware design, but still...

[jmole]

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.

[wmf]

Rogue BIOS always had total control of the system; it doesn't need exploits.