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.
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!)
> 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.
Not offering an opinion either way, but it depends. If you can exploit the kernel, you can probably do whatever you want. But if you manage to exploit the CPU firmware, you can do what you want even after the system is completely wiped.
Whether you think someone is motivated enough to find a kernel exploit that can trigger this issue and then go through the trouble of exploiting not just the kernel but this very specific CPU issue that exists on certain processors is up to you. Is it likely? I'd say no. Is it possible? Yes. Should you care? Yes. Should you lose sleep? Probably not.
Getting into SMM means you can circumvent flash protection, which means you can rewrite the firmware to backdoor the OS on every boot without needing to leave any evidence in the filesystem, which a normal compromise of ring 0 wouldn't. I don't think most people need to worry about this, but if the claims are accurate this is a genuine circumvention of a privilege boundary.
no, that is the whole point of the Secure Encrypted Virtualization hypervisor (and remember, bare-metal is just another guest). Guests should not be able to jump to hypervisor control just because they type sudo, or just because they have physical presence.
this all comes from the work AMD did on the xbox hypervisor, and obviously a console needs to be physically present (sitting in the attacker's living room) and survive a complete compromise of a guest partition (again, potentially including the OS/"bare-metal guest").
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.
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.
Isn't the question whether a firmware / BIOS / microcode invasion is detectable given that the firmware has been taken over? The answer being probably not. Except for reading the flash memory at the chip level which is most likely not provided off the shelf by the system. To be repaired, the problem needs to be noticed first.
SMM is merely a macguffin in this situation, it’s a tool to get the system into a privileged mode whereupon you buffer overflow it with a mailbox message or something. I’d really think that based on your username you have to already be aware of this?
Similar mechanisms were demoed in the ryzenfall exploit series like 5+ years ago.
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
The Ryzen 3000 series ("matisse") is less than 5 years old, with the models coming out in late 2019 and 2020. To not issue a fix for those is very disappointing.
I just built a gaming PC with a Ryzen 3600. It is more than sufficient to run modern games with demanding graphics and performance. I now need to learn about this exploit. Yes, if someone gets the level of access required to exploit it I was pwned anyway, but now if I get pwned I need to open up my computer and throw away a perfectly powerful CPU, then put it back together with a new one.
That's pretty damn frustrating. It will definitely push me away from AMD when I am making future hardware decision.
EDIT: As pointed out by sqeaky and others, there shouldn't be a method for persistence that lives on the processor, instead it would likely be on the motherboard, or in the bootloader on a storage device.
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.
I know more than one person running a Ryzen 3700X (launched 7/7/2019) or similar and it's still a perfectly solid CPU.
There are at least upgrade options compatible with the same socket, unlike a certain other CPU manufacturer, but it's not like these are really worth replacing yet.
UserBenchmark scores the 5800x3d about 17% higher for $340.
It's from the Jul 2019. Not very old. CPUs from the early 2010s, with enough ram, are still perfectly usable for light browsing and text editing tasks.
Yes, all of that but.. that's exactly the way of looking at things that a chip company like AMD are not allowed to have ( or at least to say publicly ).
The CPUs are "old" they are "limit" as an installed base but only comparing to today's AMD market share because I'm pretty sure there are hundred of thousands ( if not a few millions ) of these CPUs all over the World.
My main point is: going the extra-mile/cost to fix these cpus would be the cheaper route for them because image and credibility matters.. a lot.
I bought my 3900x just under 5 years ago. Norwegian consumer protection laws give me 5 years where the producer is required to fix any defects that came with the product.
As this bug now has become known to always have been there, i could probably force amd to replace my 3900x if they don't provide software patches.
Has anyone else attempted a similar RTM for software defects?
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
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?
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)
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.
Some (most?) motherboards now have a way to reflash a bios in "no POST" scenarios. There's either a dedicated microcontroller or it reuses the embedded controller to read a BIOS image from a USB mass storage device.
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?
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.
>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.
Readit News
(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!)
> 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.
Whether you think someone is motivated enough to find a kernel exploit that can trigger this issue and then go through the trouble of exploiting not just the kernel but this very specific CPU issue that exists on certain processors is up to you. Is it likely? I'd say no. Is it possible? Yes. Should you care? Yes. Should you lose sleep? Probably not.
this all comes from the work AMD did on the xbox hypervisor, and obviously a console needs to be physically present (sitting in the attacker's living room) and survive a complete compromise of a guest partition (again, potentially including the OS/"bare-metal guest").
https://www.youtube.com/watch?v=U7VwtOrwceo
why would ring0 ever be intended to grant you access to ring -1 or -2? why even have rings -1 or -2 in that situation?
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!
Similar mechanisms were demoed in the ryzenfall exploit series like 5+ years ago.
https://youtu.be/QuqefIZrRWc?t=1195
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...
I just built a gaming PC with a Ryzen 3600. It is more than sufficient to run modern games with demanding graphics and performance. I now need to learn about this exploit. Yes, if someone gets the level of access required to exploit it I was pwned anyway, but now if I get pwned I need to open up my computer and throw away a perfectly powerful CPU, then put it back together with a new one.
That's pretty damn frustrating. It will definitely push me away from AMD when I am making future hardware decision.
EDIT: As pointed out by sqeaky and others, there shouldn't be a method for persistence that lives on the processor, instead it would likely be on the motherboard, or in the bootloader on a storage device.
There are at least upgrade options compatible with the same socket, unlike a certain other CPU manufacturer, but it's not like these are really worth replacing yet.
UserBenchmark scores the 5800x3d about 17% higher for $340.
It's from the Jul 2019. Not very old. CPUs from the early 2010s, with enough ram, are still perfectly usable for light browsing and text editing tasks.
http://en.m.wikipedia.org/wiki/Zen_2
That's not very old.
I guess maybe they can't fix them or something. This is very bad for their reputation.
The CPUs are "old" they are "limit" as an installed base but only comparing to today's AMD market share because I'm pretty sure there are hundred of thousands ( if not a few millions ) of these CPUs all over the World.
My main point is: going the extra-mile/cost to fix these cpus would be the cheaper route for them because image and credibility matters.. a lot.
As this bug now has become known to always have been there, i could probably force amd to replace my 3900x if they don't provide software patches.
Has anyone else attempted a similar RTM for software defects?
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?
It works even when there's no CPU installed.
How is a compromised AMD CPU better than Intel's CPUs which get damaged due to oxidation and high voltage?
>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/