6 ms·
Researchers discover potentially catastrophic exploit present in AMD chips
- PedroBatista 2y agoIt 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/amd-sb-7014.html https://www.amd.com/en/resources/product-security/bulletin/a...
- molyss 2y agoI'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
- Vegenoid 2y agoThe 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.
- gruez 2y ago>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. I don't think there's any indication that the exploit allows the CPU itself to be persistently infected.
- Vegenoid 2y agoFrom the article: > As a matter of fact, the researchers say that the code would likely survive a complete reinstallation of the operating system. The best option for infected computers would be a one-way ticket to the trash heap. From the Wired article (https://www.wired.com/story/amd-chip-sinkclose-flaw/ https://www.wired.com/story/amd-chip-sinkclose-flaw/): > In fact, for any machine with one of the vulnerable AMD chips, the IOActive researchers warn that an attacker could infect the computer with malware known as a “bootkit” that evades antivirus tools and is potentially invisible to the operating system, while offering a hacker full access to tamper with the machine and surveil its activity. For systems with certain faulty configurations in how a computer maker implemented AMD's security feature known as Platform Secure Boot—which the researchers warn encompasses the large majority of the systems they tested—a malware infection installed via Sinkclose could be harder yet to detect or remediate, they say, surviving even a reinstallation of the operating system. > Only opening a computer's case, physically connecting directly to a certain portion of its memory chips with a hardware-based programming tool known as SPI Flash programmer and meticulously scouring the memory would allow the malware to be removed, Okupski says. Nissim sums up that worst-case scenario in more practical terms: “You basically have to throw your computer away.” Do you have differing information?
- sqeaky 2y agoI have no information that conflicts with what you posted but none of that indicates that the CPU gets written to. Consider that even things like CPU microcode don't get stored on the CPU, it's simply doesn't have persistent storage. CPU microcode is often applied early during OS boots and loaded into memory or CPU cache. What you have quoted indicates something similar, perhaps the main board or other device with storage of some kind is being written to or perhaps an attacker could write a payload that lived entirely in the bootloader on the main storage.
- isotypic 2y agoThe "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.
- nullifidian 2y ago>given the age of this series 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.
- arghwhat 2y agoCalling 3900 “very old” is stretching it, but they’re certainly “old”. Chips from the early 2010s are very old and inefficient - it’s just that you listed tasks that demand nothing, and if battery power is not required it will certainly do the trick. Being very old and being usable are very things, as any senior person or tech collector will tell you.
- Vegenoid 2y ago> Calling 3900 “very old” is stretching it, but they’re certainly “old”. No, I will contest <5 years old CPUs being called "old". This perspective is warped by the marketing teams of computer hardware companies. There are many 3000 series processors which are perfectly powerful enough for powerful modern software.
- spencerflem 2y agoTotally, I'm chilling with a 2016 skylake i5 and have no desire to upgrade whatsoever.
- arghwhat 2y agoTo nitpick, they are not “<5 years”, they are officially more than 5 years and one month old depending on the model. They have been superseded 3 times (5000, 7000 and now 9000), fallen off comparison charts. Even 5000 to 9000 nets you 2x real-world performance for the same power, 3000 was slower and hungrier than that. There is nothing wrong with using or intentionally buying old things that work. But being “powerful enough to run modern software” doesn’t mean more than “is AMD64 and support a minimum of 8GB of RAM”. I also have a 3rd gen intel i7’s laptop that is “powerful enough to run modern software”, but it’s still very old and incredibly power hungry for the little work it does. I also have a 14 year old car that performs its functions as well as when it was new - much to my dismay - but it’s still objectively old.
- sqeaky 2y agoThis 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
- pizlonator 2y agoWeird 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!
- dtx1 2y agoIt'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.
- wmf 2y agoVMs generally don't have access to MSRs so they can't exploit this. Also, I would expect larger cloud providers have already patched.
- mjg59 2y agoSMM 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.
- creer 2y agoIsn'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.
- mjg59 2y agoPlatform Secure Boot will measure the firmware into the TPM, so if an attacker modifies the firmware then yes, it'll be detectable. The microcode is signed so any attempt to modify it will simply result in the CPU booting with its ROM-based microcode.
- nightowl_games 2y agoLess is more. We need less surface area to attack. The most secure system is one that does not have any input.
- bastawhiz 2y agoDescription 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 2y agoOK, but... if a malicious program has ring0 access, isn't it game over anyway?
- gruez 2y agohttps://xkcd.com/1200/ https://xkcd.com/1200/
- bastawhiz 2y agoNot 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.
- dtx1 2y agoOh did they find the NSA Backdoor or are all hardware firmwares just leaking like a sieve?
- kmeisthax 2y agoThe "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 2y agoI’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.
- farawayea 2y agoThey 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 2y ago>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/ https://xkcd.com/1200/
- wmf 2y agoOriginal source: https://ioactive.com/event/def-con-talk-amd-sinkclose-universal-ring-2-privilege-escalation/ https://ioactive.com/event/def-con-talk-amd-sinkclose-univer...
- jl6 2y agoWhere 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 2y agoPersists 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.
- echoangle 2y agoCan 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?
- trebligdivad 2y agoYes, 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.
- telgareith 2y agoSome (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. It works even when there's no CPU installed.
- mjg59 2y agoThe 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)
- somat 2y agoWhats 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 2y agoHonestly! 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!)
- commercialnix 2y agoWe 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 2y agoThat'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.
- yencabulator 2y agoVideo of the talk is up at https://youtu.be/7Wp5D-a0XgE https://youtu.be/7Wp5D-a0XgE about 2h3min into the live stream.