How To Make Any AMD Zen CPU Always Generate 4 As a Random Number (theregister.com) 48
Slashdot reader headlessbrick writes: Google security researchers have discovered a way to bypass AMD's security, enabling them to load unofficial microcode into its processors and modify the silicon's behaviour at will. To demonstrate this, they created a microcode patch that forces the chips to always return 4 when asked for a random number.
Beyond simply allowing Google and others to customize AMD chips for both beneficial and potentially malicious purposes, this capability also undermines AMD's secure encrypted virtualization and root-of-trust security mechanisms.
Obligatory XKCD.
Beyond simply allowing Google and others to customize AMD chips for both beneficial and potentially malicious purposes, this capability also undermines AMD's secure encrypted virtualization and root-of-trust security mechanisms.
Obligatory XKCD.
Meh (Score:5, Funny)
Why this on the front page? 4 is a perfectly valid random number!
Re: (Score:3)
Re: Meh (Score:5, Funny)
Re: Meh (Score:3)
Re: (Score:1)
Yes, but was it observed?
It's the standard random number. (Score:2)
source. [xkcd.com]
Re: (Score:2)
Only Intel CPUs have security flaws (Score:1)
I know this because I've read it on the internet many times.
Re: (Score:3)
All you've done is demonstrate your inability to read. We've discussed AMD security flaws countless times here.
XKCD 221: "Random Number" (Score:5, Funny)
https://xkcd.com/221/ [xkcd.com]
If this isn't deliberate I'll eat my hat.
Re: (Score:2)
Congratulations, you posted a link to a page already linked in TFS titled "Obligatory XKCD"
Re: (Score:2)
not sure how this is news (Score:4, Informative)
I am not sure how this is news.
To update the microcode you need to either update the bios or get firmware placed on the machine for the kernel to load. If I can do either of those I OWN the machine anyway and can pretty much do anything to the OS and you can trust nothing.
This (Score:2)
And if you look at the linux code they've written to do it , all it does is write a microcode binary to /dev/cpu/[id]/msr
Re: (Score:2)
This.
Plus there are plenty of reasons why you might want to modify the microcode.
Re: (Score:2)
Examine the microcode for backdoors for one thing.
Re:not sure how this is news (Score:5, Informative)
To update the microcode, you're supposed to have a signed binary to load. This bypasses the requirement to have a valid signature. Hence the titled "AMD: Microcode Signature Verification Vulnerability".
If you have an exploit that allows local admin, or you are a local admin, this vulnerability escalates that to arbitrary microcode updates.
This allows a local admin to bypass AMD Secure Encrypted Virtualisation, which is supposed to stop the local admin from accessing the guest VM.
Congrats, some guy at Amazon can now access your secure VM running on AWS
Re: (Score:3)
If your VM is running on someone else's hardware, then the owner of that hardware has access to it. Attempts to obfuscate it are just that - obfuscation, and there will always be a way around it.
Re:not sure how this is news (Score:5, Insightful)
Yep. Securing a VM against the host it runs on is wishful thinking. Worst case, the host can do partial emulation and then controls everything. There is no preventing something like that unless you do actual hardware machine partition (like mainframes can do) and that pretty much is the same as using separate machines. Not going to happen anytime soon with regular hardware.
Re: (Score:2)
Even with physically separate machines, the machine still sits in someone else's datacenter. You have to trust your suppliers, and pretending you don't is just asking for trouble.
Re: (Score:2)
Even then, you're depending on the mainframe operators doing what they said they would do and not leaving themselves a way to peek.
Re: (Score:3)
Re: (Score:2)
There are some beta BIOS updates available that fix it, but they seem to have published a bit early because someone accidentally leaked some details.
Re: (Score:2)
Re: (Score:2)
There's always a question of what you do once you own a machine. There's very few methods of owning a machine that have a potential to create unremovable security backdoors. Generating the same random number is one of them.
Also to update microcode you don't need to update the bios at all. You just need to do it. A CPU can do it on the run. The earlier you do it the less likely something is to go wrong so most OSes will load the most current microcode for your CPU just before loading the system kernel. Most
Re: (Score:2)
Indeed. Still interesting from a research point-of-view.
Re: (Score:2)
Both AMD and Intel want to keep everybody except themselves out of the microcode, for no good reason. Or for backdoor reasons as has often been suggested. This is a jailbreak.
Back in the day (Score:2)
The random number function used to return a value between 0 and 1
Re:Back in the day (Score:4, Funny)
Blasphemy! There are no numbers between zero and one. Next you'll be telling me you saw a two.
Re: (Score:2)
Re: Back in the day (Score:1)
If I can't count then, I can't know for sure it's infinite. After all, maybe the next one will be the last one...
Re: (Score:2)
Re: (Score:2)
If you saw a 2, do you get a pair of ones?
Re: (Score:2)
Re: (Score:2)
This one does too! It just excludes 1, has a binary result and an offset of 4! Obvious, really.
oh dear (Score:2)
Someone took xkcd way too literally [xkcd.com].
Now what will mitigation cost (Score:2)
From my browsing around recently looking for info on BIOS versions, it looks like plenty of people skipped the last couple AGESA updates because the mitigations cost too much. I ran some benchmarks here and found 5% cost with AM4 AGESA Combo V2 PI 1.2.0.B vs AM4 AGESA Combo V2 PI 1.2.0.A on a 5600X. This still isn't as bad as most of the infamous Intel mitigations, and it's not affecting me in any way I've noticed so far so I may just continue to run this BIOS anyway — at least up until such a time as
Re: (Score:2)
Probably nothing. This already requires local admin privileges. At that time, an attacker has won. The only thing affected may be Digital Restriction Management in the form of "secure" boot, but that does not work for the user anyways and can be safely done without.
Re: (Score:2)
I very much do not want someone who has successfully attacked my software to also be able to attack my hardware, which is what they can do if they can replace my microcode with Folger's Crystals.
Re: Now what will mitigation cost (Score:2)
So its not the best part of waking up?
Requires local admin privileges (Score:4, Insightful)
At that time, it becomes pretty irrelevant. The attacker has won.
Still interesting from a research perspective though, but not from a practical one.
Re: (Score:2)
At that time, it becomes pretty irrelevant. The attacker has won.
Still interesting from a research perspective though, but not from a practical one.
There is still a recovery to consider (you can't re-image out of this).
Side note: You do not need "random" for security (Score:2)
You need "unpredictable for an attacker". Subtle but important difference.
In the case at hand, "4" is random (for some definitions), but it is not unpredictable for any sane definition of unpredictable.
Prior Art (Score:1)
https://www.youtube.com/watch?... [youtube.com]