News You can now jailbreak your AMD CPU' — Google researchers release kit to exploit microcode vulnerability in Ryzen Zen 1 to Zen 4 chips

Well, that sounds fun! Anyone interested in helping reverse-engineer Zen's microcode should read their blog and follow the links.

At the end of the post, they share this inspirational tidbit:

"Previous research on Intel microcode has demonstrated the ability to craft new instructions to implement security features similar to ARM’s pointer authentication codes, accessing internal CPU buffers, tracing microcode, and more."

Even just understanding the instruction set of the micro ops should give a much deeper insight into how these CPUs actually work.
 
To be honest this is an absolute disaster of an exploit, and the amused headline really doesn't reflect how bad it is. This has to be one of the worst secure vulnerabilities ever found on AMD or Intel CPU's.
 
Am I the only one that has trouble keeping a Windows key active after a bios flash with a ftpm setup?
If I had one of these chips and I was looking at keeping the vulnerability or keeping 15 bucks for a new key, and it wasn't my office PC I would be torn on whether it was worth it.
 
This isn't as serious as the closing paragraph suggests. Microcode updates are not permanent; they're stored in a special microcode RAM that loses its contents just like system RAM does when it loses power.

Microcode is first loaded from the microcode ROM burned in at time of manufacture, then updated by the BIOS if it has a newer version available, then finally updated by the OS if it has an even newer version than the BIOS does. A power cycle starts this process all over again.

Quote from the "Future Work" section of the Bug Hunters breakdown:
Luckily, the security impact was limited by the fact that attackers must first obtain host ring 0 access in order to attempt to install a microcode patch and that these patches do not persist through a power cycle.

This means that, unlike randomly found USB flash drives, used Zen 1-4 CPUs are just as safe as new CPUs.
 
To be honest this is an absolute disaster of an exploit, and the amused headline really doesn't reflect how bad it is. This has to be one of the worst secure vulnerabilities ever found on AMD or Intel CPU's.
You have much bigger problems if somebody already has local admin access on your machine.
 
  • Like
Reactions: Thunder64
Lenovo locks their AMD CPUs I think. I suspect people might try simply reversing that lock, moreso than random payload deliveries to unknown ebay buyers.
According to the blog post, the microcode doesn't persist across reboots. There's a microcode ROM, that's either non-writable or at least not affected by this exploit, and a microcode RAM. This exploit only lets you modify the RAM, which means that if you don't hack the BIOS or the machine's software, it will no longer have the modified microcode after a reboot.

Or read silentdude56k's post.
 
And there's the problem: Not every board will get this patch. Even my high-end Gigabyte X570S Aorus Master hasn't been updated since September of last year, with "Update AMD AGESA 1.2.0.Cc for fix Sinkclose Vulnerability of AMD processors" being it.

Granted this bug falls clearly into the "If you have admin privileges in the hands of a bad actor you have bigger problems" camp, it does serve as a reminder how less and less secure even quite sufficiently fast CPUs become over what could be a relatively short period of time.
 
And there's the problem: Not every board will get this patch. Even my high-end Gigabyte X570S Aorus Master hasn't been updated since September of last year, with "Update AMD AGESA 1.2.0.Cc for fix Sinkclose Vulnerability of AMD processors" being it.
You can get patched via your OS, although that has the downside that something in your OS' boot time that runs before microcode update could theoretically install hacked microcode before the microcode update runs. However, I'm pretty sure microcode update runs quite early during OS boot.

Granted this bug falls clearly into the "If you have admin privileges in the hands of a bad actor you have bigger problems" camp, it does serve as a reminder how less and less secure even quite sufficiently fast CPUs become over what could be a relatively short period of time.
Well, the earliest CPU it affects is Zen 1. If nobody found it 'till now, then that's a pretty good long run. Then again, somebody in some government agency could've founding on day 2 after Zen's launch and been exploiting it this whole time.

I think it's perhaps more interesting Zen 5 isn't affected. Now, I recall that AMD enlarged the microcode RAM (?) for Zen 5, so maybe the only reason it's unaffected is incidental, or maybe they've been sitting on it for quite a while?
 
For a personal or work computer this isn't really a big deal. It's not a total nothing burger like all of the vulnerabilities you hear about but the attacker needs physical access to the machine.

In this case as others have said if you have a malicious actor with admin access to your machine there are a laundry list of nastier, more permanent things he or she could do to compromise you.

Where this is a much bigger deal is for servers or machines relying on virtualization, containers, sandboxes, or anywhere there is a need to keep things silo'd.
 
Where this is a much bigger deal is for servers or machines relying on virtualization, containers, sandboxes, or anywhere there is a need to keep things silo'd.
That's right. Unless I'm missing something I think that AMD-SEV feature is pretty much bricked at this point for Zen 4. I don't understand how a VM can now receive a trustworthy attestation report if the microcode can be compromised.
 
  • Like
Reactions: bit_user