Hacker News new | ask | show | jobs
by gruez 681 days 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.

1 comments

From 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/):

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

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

Not 100% true - a microcode-based CPU without microcode isn't able to execute anything, so CPUs will ship with an early version of the microcode that's then (as you say) updated during boot.
So I believe this rules out a supply chain attack where someone buys a bunch of CPUs, infects them, repackages them and sells them as new.

If you can't do that, then this feels significantly less problematic.

They could potentially do that to motherboards, but they could do that anyway (physical access would give you as much access to flash as this vulnerability does). But yes, CPUs should be fine in that respect.
But that doesn't persist through reboots, does it?
Correct, the update has to be applied on every boot, but that doesn't mean there's no microcode in the CPU itself
And that information is clearly irrelevant and misleading in this context.
Appreciate the clarification, that makes sense. Maybe we'll get more details on potential persistence methods from the talk they'll give tomorrow: https://info.defcon.org/event/?id=54863
Looks like the motherboard would have to be thrown away, not the CPU, even if the vulnerability was facilitated by the CPU.

> For systems with certain faulty configurations in how a computer maker implemented AMD's security feature known as Platform Secure Boot

Seems like this actually requires two vulnerabilities, then?

That just sounds like they can install a rogue bootloader, bypass secureboot, or hide from the operating system by operating on a higher privilege level than it. I don't see how it can infect the CPU itself, or how the infection can persist after swapping out the hard drives.
Jesus, that's catastrophic. They weren't kidding. "No fix planned" isn't acceptable.