AMD 'Zenbleed' Bug Leaks Data From Zen 2 Ryzen, EPYC CPUs (tomshardware.com) 40
Monday a researcher with Google Information Security posted about a new vulnerability he independently found in AMD's Zen 2 processors. Tom's Hardware reports:
The 'Zenbleed' vulnerability spans the entire Zen 2 product stack, including AMD's EPYC data center processors and the Ryzen 3000/4000/5000 CPUs, allowing the theft of protected information from the CPU, such as encryption keys and user logins. The attack does not require physical access to the computer or server and can even be executed via JavaScript on a webpage...
AMD added the AMD-SB-7008 Bulletin several hours later. AMD has patches ready for its EPYC 7002 'Rome' processors now, but it will not patch its consumer Zen 2 Ryzen 3000, 4000, and some 5000-series chips until November and December of this year... AMD hasn't given specific details of any performance impacts but did issue the following statement to Tom's Hardware: "Any performance impact will vary depending on workload and system configuration. AMD is not aware of any known exploit of the described vulnerability outside the research environment..."
AMD describes the exploit much more simply, saying, "Under specific microarchitectural circumstances, a register in "Zen 2" CPUs may not be written to 0 correctly. This may cause data from another process and/or thread to be stored in the YMM register, which may allow an attacker to potentially access sensitive information."
The article includes a list of the impacted processors with a schedule for the release of the updated firmware to OEMs.
The Google Information Security researcher who discovered the bug is sharing research on different CPU behaviors, and says the bug can be patched through software on multiple operating systems (e.g., "you can set the chicken bit DE_CFG[9]") — but this might result in a performance penalty.
Thanks to long-time Slashdot reader waspleg for sharing the news.
AMD added the AMD-SB-7008 Bulletin several hours later. AMD has patches ready for its EPYC 7002 'Rome' processors now, but it will not patch its consumer Zen 2 Ryzen 3000, 4000, and some 5000-series chips until November and December of this year... AMD hasn't given specific details of any performance impacts but did issue the following statement to Tom's Hardware: "Any performance impact will vary depending on workload and system configuration. AMD is not aware of any known exploit of the described vulnerability outside the research environment..."
AMD describes the exploit much more simply, saying, "Under specific microarchitectural circumstances, a register in "Zen 2" CPUs may not be written to 0 correctly. This may cause data from another process and/or thread to be stored in the YMM register, which may allow an attacker to potentially access sensitive information."
The article includes a list of the impacted processors with a schedule for the release of the updated firmware to OEMs.
The Google Information Security researcher who discovered the bug is sharing research on different CPU behaviors, and says the bug can be patched through software on multiple operating systems (e.g., "you can set the chicken bit DE_CFG[9]") — but this might result in a performance penalty.
Thanks to long-time Slashdot reader waspleg for sharing the news.
Bleed (Score:2)
I always felt my processors could use a good bleeding.
ZenBleed info (Score:5, Informative)
I found a supplementary article that gives a basic overview of the bug.
Zenbleed: Everything you need to know [xda-developers.com]
Too Afraid of Market Backlash? (Score:3)
but it will not patch its consumer Zen 2 Ryzen 3000, 4000, and some 5000-series chips until November and December of this year
Makes me wonder if the performance hit is just too much with the current patch and they're afraid of losing market share because of it. They've had a good run with Ryzen.
microcode (Score:3, Informative)
Re: (Score:1)
Playboy? No one reads playboy. This isn't the 80s. Obviously they're not reading playboy.
However, they are watching porn all day.
Re: (Score:2)
Re: microcode (Score:2)
Re: (Score:3)
You would have a better chance of getting hit by lightning than manage an exploit via JavaScript. Is it technically possible? Yes. do any javascript virtual machines actually utilize the instructions impacted? Nope. What you really need is to be able to execute a specifically crafted set of instructions in order to really exploit it.
It affects a whole bunch of Ryzen processors which aren't meant for the data centers.
The lion's share of profits come from server CPUs, which is why they are first. Again, javascript is a non-issue.
Coming up with a microcode update should not take 5 months.
Coming up with a microcode update only takes a day or two at mo
Re: (Score:1)
You would have a better chance of getting hit by lightning than manage an exploit via JavaScript. Is it technically possible? Yes. do any javascript virtual machines actually utilize the instructions impacted? Nope. What you really need is to be able to execute a specifically crafted set of instructions in order to really exploit it.
The bug involves leaving prior data in the YMM registers during a switch to a new context.
Normally, a new context has them reset to zeros, and context switching restores the previous values for that context.
New processes (threads) will not get zeros, but some other processes YMM data instead, due to the bug.
XMM and YMM registers are used by many opcodes and extended instructions.
SSE, AVX, VEX, likely others as well.
Quite a few of those are available to access inside a JS VM.
It is questionable how much initi
Re: (Score:2)
When you do predicted code execution, your data _must_ stay physically where it is, so that it can be restored if the prediction failed. So while you are executing predicted code, other processes must be prevented from writing to the physical location. For two obvious reasons: One, if another process can write to that location, and then my process decides the branch was mispredicted and tries to restore the data, then my process gets incorrect data and probably crash
Re: (Score:2)
You would have a better chance of getting hit by lightning than manage an exploit via JavaScript. Is it technically possible? Yes. do any javascript virtual machines actually utilize the instructions impacted? Nope. What you really need is to be able to execute a specifically crafted set of instructions in order to really exploit it.
It affects a whole bunch of Ryzen processors which aren't meant for the data centers.
The lion's share of profits come from server CPUs, which is why they are first. Again, javascript is a non-issue.
Coming up with a microcode update should not take 5 months.
Coming up with a microcode update only takes a day or two at most. What takes the most time is finding the optimal solution and testing it.
If you're really concerned about it then there is the "chicken bit" which allows you to disable the feature entirely.
I suspect that the microcode fix is to block other firmware from exploiting the bug while it is doing something it was designed to do that won't be fixed. Without researching the matter at all so again, it's just a suspicion. Sooo... watch your Rust code because I also suspect this bug is exploitable with it IDK.
Re: (Score:2)
Re: (Score:2)
> the fact that it's exploitable via Javascript in a browser
That doesn't seem to be a fact - just a claim somebody made.
Based on Cloudflare's blog it's probably only technically true on 4+-yr old browsers without timing-attack mitigation features.
Practically it appears to not be true for any modern use case.
Re: (Score:3)
This is a pretty low priority because multi-user systems typically run Epyc not Ryzen.
They say the exploit can even be run via javascript (and presumably other sandboxed languages that we usually think of as safe), so it could be a viable attack even against a typical desktop machine only used by one person.
Also, even the /. summary makes it clear that Epyc is affected as well.
The 'Zenbleed' vulnerability spans the entire Zen 2 product stack, including AMD's EPYC data center processors and the Ryzen 3000/4000/5000 CPU
Re: (Score:2)
They say the exploit can even be run via javascript
Tom's hardware makes that claim. However, no evidence has been presented that javascript VMs can trigger this bug. It can be reliably triggered using a nonsensical string of instructions but no evidence has been presented showing that javascript can pull this off.
Re: (Score:2)
The instruction with the broken rollback is going to be hit frequently due to its use in libc.
After that, there are 2 things that the CPU must be triggered to do in order to force it into a broken state. These things have to be done in a semi-strict timing window, but they do not have to be issued sequentially. Both of those things will also be done in libc, though triggering them via a JS VM will require intimate knowledge of the JIT. Absolutely doable though.
Trivial t
Re: (Score:2)
triggering them via a JS VM will require intimate knowledge of the JIT. Absolutely doable though.
If you were certain that the instruction was used, then maybe. However, you don't even know if it is.
Re: (Score:2)
If you were certain that the instruction was used, then maybe.
Yup. Not maybe, then yes. The conditional is very plain. If this, then that.
However, you don't even know if it is.
There's zero chance whatsoever that this can't happen.
As I said earlier, they're all prevalent within libc for good reason- they're part of modern vectorization optimizations.
There's no fucking chance in hell that a modern JS JIT VM doesn't use the faulty instruction, or the the instructions that trigger the faulty rollback.
There has been speculation that Spectre mitigations for JS will be helpful here, but I don't really see ho
Re: (Score:2)
There's zero chance whatsoever that this can't happen.
So I decided to stop guessing and cloned and searched the source code for Chromium's V8 engine [googlesource.com] and Firefox [github.com] which bundles it's SpiderMonkey engine.
For V8, I ran grep -ir "vzeroupper" v8/ and it returned nothing at all.
For Firefox, SpiderMonkey is the "js/src" directory. so I did grep -ir "vzeroupper" gecko-dev/js/src/ and the returned results were all from the "gecko-dev/js/src/zydis/" which is a copy of the
Zydis x86_64 disassembler (see https://github.com/zyantific/z... [github.com]).
vzeroupper is not used in JavaScrip
Re: (Score:2)
Why on earth do you think you could pull C and C++ source, and grep for an assembly mnemonic?
You didn't pick up that you may have been barking up the wrong tree when the only place you found the mnemonic was in a disassembled that turns machine code into mnemonics?
Re: (Score:2)
I used IDA Pro for the disassembly, but Ghidra is a great free option if you'd like to take a poke yourself.
vzeroupper is used in 1 single function in v8, fast_search_avx (and all of its polymorphisms)
I didn't track down exactly which intrins
Re: (Score:2)
Re: (Score:2)
I may not be the ideal person to ask -- I just read the summary and skimmed over the links given in it.
That said, the summary says "AMD has patches ready for its EPYC 7002 'Rome' processors now", and AMD's response talks about that and "AMD Ryzen 7020 Series Processors", so ... I guess yes?
I've got several Ryzen machines, but most are 2xxx so I guess they're not vulnerable, but one is a 5500 so I guess that is. It doesn't strike me as a large concern in my specific case, but it's easy to see common cases w
Re: (Score:2)
Re: (Score:2)
The Javascript exploit is probably a very remote possibility, given that it seems to rely on a low probability event occurring. In other words you need to run the Javascript a lot, and all modern browsers throttle Javascript execution quite aggressively to save power and reduce system load. There are exceptions, mainly Javascript that the user is directly interacting with, but even if you could engineer the user doing that for a while... ...the next problem is that you get the content of one register at a r
Re: (Score:3)
IIUC Linux kernel 6.4.6 onward has a Zenbleed fix until the firmware updates arrive.
Re: (Score:2)
Makes me wonder if the performance hit is just too much with the current patch and they're afraid of losing market share because of it. They've had a good run with Ryzen.
Likely. People are interested in performance. All of these attacks are incredibly hard to pull of outside of a lab or a situation where you already have access to the hardware. Sure it sounds nasty that a website can run javascript to exfiltrate data, but actually knowing what to exfiltrate and when is not only non-trivial, it's prohibitive in the schemes of more successful hacks (e.g. social engineering).
There's a reason every one of these vulnerabilities so far have been opt-in. Performance matters more t
Not vulnerable to javascript (Score:5, Informative)
https://blog.cloudflare.com/ze... [cloudflare.com]
"Given that the successful exploitation of this vulnerability requires very precise timing that is difficult to achieve without executing native code the vulnerability, filed under CVE-2023-20593, has initially received the CVSS score of 6.5 and therefore was classified as Medium Risk. The initial mitigation suggested by the researcher is achieved by turning off certain functionality via modification of the Model Specific Register - namely DE_CFG. This change will prevent certain instructions with complex side effects like vzeroupper from being speculatively executed. "
Re: (Score:2)
All of these CPU vulnerabilities over the past several years are incredibly difficult to exploit. I haven't heard of a single one of them being successfully exploited in the wild. Not to say we shouldn't try to fix them, but from a hacker's point of view there are much easier and cheaper ways to successfully attack an organization.
Re: (Score:2)
Meltdown was allegedly a pretty high-risk vulnerability
Re: (Score:2)
Re: (Score:2)
I don't have the expert knowledge to answer if on my own, but I've asked and I've gotten the answer that it would be nearly impossible to both craft the exact instructions necessary to initiate the exploit and read the correct registers at exactly the right times to get the CPU to leak useful data.
My impression is that it would take a carefully-crafted compiled binary to pull it off.
Amusing that only Zen2 is affected (Score:2)
Presumably this instruction exists in Zen1. Since the functionality would be useful for AVX there too.
So, VZEROUPPER internally changed from Zen1 to Zen2 and then changed back again in Zen3 - All without anyone noticing there was a problem in Zen2.
Desktop fixes N/A. Zen 3 on appears not affected. (Score:1)
This gives a good summary, impact assessment and fix ETAs for affected AMD Zen 2 CPUs:
Encryption-breaking, password-leaking bug in many AMD CPUs could take months to fix [arstechnica.com]
I'm glad this appears to only affect an older family of AMD Zen 2 CPUs i.e. does NOT affect AMD Zen 3 and later CPUs.
Odd that fixes are N/A for Desktop Zen 2 CPUs with old server AMD Zen 2 CPU microcode patched now. This seems like a weird delayed response to something that can lose passwords and encryption keys.
Warning: running Internet sou
Prehaps adapt a proof-checker? (Score:2)
Microcode can be pretty gnarly, even compared to assembler. Perhaps the solution is to adapt a proof checker from math to microcode. I wouldn't expect it to be a trivial exercise, but it appears as if it could be quite valuable to do.
And, who cares? (Score:1)
Just an ordinary bug (Score:2)
If you write totally non-malicious code that does a lot of 256 bit XMM operations, and you are unlucky and use an unfortunate sequence of instructions, then it can happen that another process also using totally non-malicious code doing the same overwrites the upper half of one of your 256 bit XMM registers. Requires a lot of bad luck, but it could affect your program badly obviously.
Now if you replace your code with some malicious code, then your code can perfor
Re: (Score:2)
then the attacker might be able to read 16 of these 10,000 bytes.
More, if you happened to be scheduled as a second running thread on the core.
I agree that in the case of OS scheduled sharing of a core, the memcpy is likely to complete in a single time slice.