How To Make Any AMD Zen CPU Always Generate 4 As a Random Number (theregister.com) 62
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:2, Flamebait)
I know this because I've read it on the internet many times.
Re: (Score:2, Informative)
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)
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)
Indeed. And physical access usually comes with possibilities for full compromise.
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:2)
Indeed. And same for the mainframe suppliers. I trust, for example, IBM as far as I can throw them.
Re:not sure how this is news (Score:4, Interesting)
This required signature scam is bullshit.
Re: (Score:2)
The CPU was never sold to you as something you can update the microcode yourself.
This isn't the same as drivers for your OS.
A physical jumper makes no sense. The microcode is stored in non-volatile memory in the CPU. It gets updated every time you boot it.
If it's a bad update, or something happens during the load, a reset will fix it.
Imagine how annoyed people would get if they bumped the reset button while their computer was booting, or the battery went flat at the wrong time and it bricked the CPU.
Or the
Re: (Score:2)
Re: (Score:2)
You may think it shouldn't, but it does.
Not just the hard drive. The BIOS can update it too.
The fact the CPU has no non-volatile writable memory would be the main reason.
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:3)
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.
Re: (Score:2)
Aren't they encrypted and signed ? And not like UEFI where you can add a custom signing authority. à
I kinda remember intel's microcode signature getting powned at some point too.
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:5, Funny)
Blasphemy! There are no numbers between zero and one. Next you'll be telling me you saw a two.
Re: (Score:2)
Re: (Score:1)
A number between 0 and 1 is clearly finite.
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:1)
Someone took xkcd way too literally [xkcd.com].
Now what will mitigation cost (Score:3)
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 the performance becomes an issue for some reason that I think I can solve with only 5% more processing power.
From what I've seen, on average mitigation is cheaper on AMD, but there's always next time. Or, perhaps, this time.
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?
Re: (Score:2)
Anybody with root can already flash a new BIOS (or a really old one with known vulnerabilities), overwrite your RAM parameters and probably maybe cook your CPU. This attack is not that special.
Requires local admin privileges (Score:3, 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).
Re: (Score:2)
There is still a recovery to consider (you can't re-image out of this).
Anybody with root access can flash you a new BIOS. Or an old one with known vulnerabilities. Even "protected" areas in BIOS FLASH chips are not really protected.
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.
Re: (Score:2)
Why would anybody mod this down? Some people are simply insane.
Re: (Score:2)
Perhaps you have not provided a useful example outlining your supposed distinction between random and unpredictable?
Prior Art (Score:1)
https://www.youtube.com/watch?... [youtube.com]
A decade or two ago we would have called this good (Score:3)
<slashdotter years_ago=20>
AMD's microcode is jailbroken! Hooray! Let a thousand custom ROMs bloom!
Rootkit? What's that?
</slashdotter>
I'm not sure; it might still turn out to be useful even today.