"Zenbleed" bug affects all Zen 2-based Ryzen, Threadripper, and EPYC CPUs.
The bug allows attackers to swipe data from a CPU’s registers. […] the exploit doesn’t require physical hardware access and can be triggered by loading JavaScript on a malicious website.
Okay, I’ve been reading the coverage of this and it seems like there is a lot of misconception going around especially in the comment sections of the various news articles. And then those comments sometimes get picked up and put into other news articles etc…
First things first, check out the blog post from the guy who discovered the bug, Travis Ormandy
https://lock.cmpxchg8b.com/zenbleed.html
It also looks like there was a timeline in the readme of the github repo from Travis
Timeline
2023-05-09 A component of our CPU validation pipeline generates an anomalous result.
2023-05-12 We successfully isolate and reproduce the issue. Investigation continues.
2023-05-14 We are now aware of the scope and severity of the issue.
2023-05-15 We draft a brief status report and share our findings with AMD PSIRT.
2023-05-17 AMD acknowledge our report and confirm they can reproduce the issue.
2023-05-17 We complete development of a reliable PoC and share it with AMD.
2023-05-19 We begin to notify major kernel and hypervisor vendors.
2023-05-23 We receive a beta microcode update for Rome from AMD.
2023-05-24 We confirm the update fixes the issue and notify AMD.
2023-05-30 AMD inform us they have sent a SN (security notice) to partners.
2023-06-12 Meeting with AMD to discuss status and details.
2023-07-20 AMD unexpectedly publish patches, earlier than an agreed embargo date.
2023-07-21 As the fix is now public, we propose privately notifying major distributions that they should begin preparing updated firmware packages.
2023-07-24 Public disclosure.
It looks like a microcode fix is already in place for the most affected security scenario which is datacenters running virtual machines on EPYC Rome generation server CPUs, where the danger is a malicious user leaking data from the cpu registers holding another user’s data. The danger to individuals running zen 2 CPUs in their own personal computers or in PS5/Xbox Series X/S and Steam Decks or other handhelds is a bit more nebulous.
There has been speculation that it might be possible to use this exploit on javascript in a browser. But I can’t find any concrete evidence that this has been worked out yet. The exploit from Travis is written in C and assembly and requires some specific timing to get the misprediction to occur reliably and even then there is no way to target specific processes. the exploit just offers a falsely available half a register as “free to use” another process requests register space and writes something to the “free to use” register before the branch misprediction resolves and calls back the register ownership and the malicious process reads what was left in the half a register. What ends up in that register could be a password or cryptographic key, or it could be a chunk of HTML or a UUID, or who knows what. So what you have is a box that spits out a bunch of keys, key like looking things, and blobs of malformed metal, and doesn’t tell you explicitly which is which or point you at the locks the keys go to.
This is much easier to get the timing reliably right when executing a bare binary. But when you are running javascript in a browser, you don’t get as fine grained control over the host processor and the timing. I won’t rule it out completely. But like I said, I have yet to see it be fully demonstrated. Give it a week, maybe someone will have figured it out. If someone does get a proof of concept running in javascript, then disable automatic javascript execution in your browser, or do as Travis outlined in his blog post and learn how to flip the chicken bit while you wait for microcode to filter down through your OS updates or your motherboard vendor to issue a Bios patch.
Another thing to keep in mind, the largest SIMD register on Zen2 is a 256bit register or 32 Bytes/characters. This exploit works by offering a half a register for unsuspecting processes to write data to, meaning 16 bytes/characters of data at a time. Please use passwords longer than 16 characters.
largest SIMD register on Zen2 is a 256bit register or 32 Bytes/characters. This exploit works by offering a half a register for unsuspecting processes to write data to, meaning 16 bytes/characters of data at a time. Please use passwords longer than 16 characters
This attack doesn’t target passwords “typed by users”, but AES binary passwords, which are either 128 or 256 bit long. Particularly it targets password used very often, like disk encryption passwords (both on end-user and server machines) or RAM encryption passwords (mostly used for securing VMs on servers).
What ends up in that register could be a password or cryptographic key, or it could be a chunk of HTML or a UUID, or who knows what.
It just happens that those same SIMD registers, are used to speed up encryption/decryption operations, so there is a very high chance of whatever data a malicious program manages to extract, to be either part of the key (about 30% chance), part of some random data either encrypted or decrypted (about 30% each), or a small chance of something else.
there is no way to target specific processes
when you are running javascript in a browser, you don’t get as fine grained control over the host processor and the timing
Given that the attack can be executed millions of times per second, even with a low chance of hitting the right timing, the “beauty” of these attacks is that most of the time you will get the same data, which will be either detectable as “unsuccessful”, or part of the disk/RAM encryption password. Simply running them for long enough, then looking at which data repeated the most, is going to give you the passwords to the most often running encryption processes.
The difference in impact to servers vs. user machines, is only because a server running the same software 24/7 is more likely to return meaningful data, than a user opening and closing random browser tabs, playing games, or turning the whole thing off.
Still, if the user has disk encryption enabled, that key is likely to be extracted even with a piece of JavaScript that fails the attack most of the time.
I suppose that is a good point. look for repeating chunks of data to get hardware encryption keys. However, the main point I want to stress remains that a javascript version is yet to be proven. Cloudflare edited their original statement yesterday from “The attack can even be carried out remotely through JavaScript on a website, meaning that the attacker need not have physical access to the computer or server.” to today “While there might be a possibility to execute this attack via the browser on the remote machine it hasn’t been yet demonstrated.” https://blog.cloudflare.com/zenbleed-vulnerability/
This was the main piece of misinformation I wanted to dispel. It is still up in the air whether regular people with home computers need to be panicking. Thank you for also pointing out that this isn’t primarily targeting passwords “typed by users.”
The JavaScript vector is a reasonable extrapolation based on how similar attacks like Meltdown, Spectre, or Heartbleed, eventually got their JavaScript exploits. There may not be one yet, but there’s likely to be one at some point.
It is still up in the air whether regular people with home computers need to be panicking.
That one’s easy: no, they don’t.
Even if an attacker were to get the disk encryption key from a regular user through some malicious JavaScript, the chances of them being able to actually exploit it, are slim to none. They’d still need some extra way to use that key, which would require a separate exploit, or physical access.
If it were a company computer, or the user got personally targeted (espionage, trade secrets, law enforcement, etc.)… then maybe worry a bit.
Hosting providers with shared servers, need to panic a lot. Anyone running a public server, be it at a provider or at home, should also panic a bit.
Tailscale… accessible from where? It would likely require an attacker to jump from the endpoint to a vulnerable application (or SSH) which, while possible, seems improbable. Maybe over time as the exploit gets packaged in more suites, or if targeted personally.
On the VPS, check cpuinfo to see if it’s one of the vulnerable ones. If it is, then I’d either ask them directly, avoid that kind of VPS for a while, or use it for non-sensitive stuff until it gets a fix.
ARM… will have its day. Speculative branching is too tempting to ignore, and too difficult to implement flawlessly. Just give them time 😉
So what you have is a box that spits out a bunch of keys, key like looking things, and blobs of malformed metal, and doesn’t tell you explicitly which is which or point you at the locks the keys go to.
Man, I feel like this could be a cool art installation.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !technology@beehaw.org
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Okay, I’ve been reading the coverage of this and it seems like there is a lot of misconception going around especially in the comment sections of the various news articles. And then those comments sometimes get picked up and put into other news articles etc…
First things first, check out the blog post from the guy who discovered the bug, Travis Ormandy https://lock.cmpxchg8b.com/zenbleed.html It also looks like there was a timeline in the readme of the github repo from Travis
Timeline
2023-05-09 A component of our CPU validation pipeline generates an anomalous result.
2023-05-12 We successfully isolate and reproduce the issue. Investigation continues.
2023-05-14 We are now aware of the scope and severity of the issue.
2023-05-15 We draft a brief status report and share our findings with AMD PSIRT.
2023-05-17 AMD acknowledge our report and confirm they can reproduce the issue.
2023-05-17 We complete development of a reliable PoC and share it with AMD.
2023-05-19 We begin to notify major kernel and hypervisor vendors.
2023-05-23 We receive a beta microcode update for Rome from AMD.
2023-05-24 We confirm the update fixes the issue and notify AMD.
2023-05-30 AMD inform us they have sent a SN (security notice) to partners.
2023-06-12 Meeting with AMD to discuss status and details.
2023-07-20 AMD unexpectedly publish patches, earlier than an agreed embargo date.
2023-07-21 As the fix is now public, we propose privately notifying major distributions that they should begin preparing updated firmware packages.
2023-07-24 Public disclosure.
It looks like a microcode fix is already in place for the most affected security scenario which is datacenters running virtual machines on EPYC Rome generation server CPUs, where the danger is a malicious user leaking data from the cpu registers holding another user’s data. The danger to individuals running zen 2 CPUs in their own personal computers or in PS5/Xbox Series X/S and Steam Decks or other handhelds is a bit more nebulous.
There has been speculation that it might be possible to use this exploit on javascript in a browser. But I can’t find any concrete evidence that this has been worked out yet. The exploit from Travis is written in C and assembly and requires some specific timing to get the misprediction to occur reliably and even then there is no way to target specific processes. the exploit just offers a falsely available half a register as “free to use” another process requests register space and writes something to the “free to use” register before the branch misprediction resolves and calls back the register ownership and the malicious process reads what was left in the half a register. What ends up in that register could be a password or cryptographic key, or it could be a chunk of HTML or a UUID, or who knows what. So what you have is a box that spits out a bunch of keys, key like looking things, and blobs of malformed metal, and doesn’t tell you explicitly which is which or point you at the locks the keys go to.
This is much easier to get the timing reliably right when executing a bare binary. But when you are running javascript in a browser, you don’t get as fine grained control over the host processor and the timing. I won’t rule it out completely. But like I said, I have yet to see it be fully demonstrated. Give it a week, maybe someone will have figured it out. If someone does get a proof of concept running in javascript, then disable automatic javascript execution in your browser, or do as Travis outlined in his blog post and learn how to flip the chicken bit while you wait for microcode to filter down through your OS updates or your motherboard vendor to issue a Bios patch.
Another thing to keep in mind, the largest SIMD register on Zen2 is a 256bit register or 32 Bytes/characters. This exploit works by offering a half a register for unsuspecting processes to write data to, meaning 16 bytes/characters of data at a time. Please use passwords longer than 16 characters.
Any word on Nintendo Wii patches? I want to play sports resort, but I don’t want to get hacked: 😞
Good writeup, but…
This attack doesn’t target passwords “typed by users”, but AES binary passwords, which are either 128 or 256 bit long. Particularly it targets password used very often, like disk encryption passwords (both on end-user and server machines) or RAM encryption passwords (mostly used for securing VMs on servers).
It just happens that those same SIMD registers, are used to speed up encryption/decryption operations, so there is a very high chance of whatever data a malicious program manages to extract, to be either part of the key (about 30% chance), part of some random data either encrypted or decrypted (about 30% each), or a small chance of something else.
Given that the attack can be executed millions of times per second, even with a low chance of hitting the right timing, the “beauty” of these attacks is that most of the time you will get the same data, which will be either detectable as “unsuccessful”, or part of the disk/RAM encryption password. Simply running them for long enough, then looking at which data repeated the most, is going to give you the passwords to the most often running encryption processes.
The difference in impact to servers vs. user machines, is only because a server running the same software 24/7 is more likely to return meaningful data, than a user opening and closing random browser tabs, playing games, or turning the whole thing off.
Still, if the user has disk encryption enabled, that key is likely to be extracted even with a piece of JavaScript that fails the attack most of the time.
I suppose that is a good point. look for repeating chunks of data to get hardware encryption keys. However, the main point I want to stress remains that a javascript version is yet to be proven. Cloudflare edited their original statement yesterday from “The attack can even be carried out remotely through JavaScript on a website, meaning that the attacker need not have physical access to the computer or server.” to today “While there might be a possibility to execute this attack via the browser on the remote machine it hasn’t been yet demonstrated.” https://blog.cloudflare.com/zenbleed-vulnerability/
This was the main piece of misinformation I wanted to dispel. It is still up in the air whether regular people with home computers need to be panicking. Thank you for also pointing out that this isn’t primarily targeting passwords “typed by users.”
The JavaScript vector is a reasonable extrapolation based on how similar attacks like Meltdown, Spectre, or Heartbleed, eventually got their JavaScript exploits. There may not be one yet, but there’s likely to be one at some point.
That one’s easy: no, they don’t.
Even if an attacker were to get the disk encryption key from a regular user through some malicious JavaScript, the chances of them being able to actually exploit it, are slim to none. They’d still need some extra way to use that key, which would require a separate exploit, or physical access.
If it were a company computer, or the user got personally targeted (espionage, trade secrets, law enforcement, etc.)… then maybe worry a bit.
Hosting providers with shared servers, need to panic a lot. Anyone running a public server, be it at a provider or at home, should also panic a bit.
deleted by creator
Tailscale… accessible from where? It would likely require an attacker to jump from the endpoint to a vulnerable application (or SSH) which, while possible, seems improbable. Maybe over time as the exploit gets packaged in more suites, or if targeted personally.
On the VPS, check cpuinfo to see if it’s one of the vulnerable ones. If it is, then I’d either ask them directly, avoid that kind of VPS for a while, or use it for non-sensitive stuff until it gets a fix.
ARM… will have its day. Speculative branching is too tempting to ignore, and too difficult to implement flawlessly. Just give them time 😉
deleted by creator
Man, I feel like this could be a cool art installation.
deleted by creator
I suppose that after Intel got their reaming, AMD was due for theirs. Any word on related vulns targeting ARM?
This is shaping up to be a real mess, a ton of companies are looking at whole fleet upgrades if they don’t wanna wait around for patches.
This is why you have especially generous bug bounty programs folks. :(
This is really bad. Mostly because there’s nothing to be done other than shutting down any of the affected processors until some time in the fall.
My desktop still on Zen+ 👀
All of a sudden I feel a lot happier with my 1800X. ☺️
Doesn’t AMD already have the fix for this out?
The article says there was a fix for a specific set of server CPUs, but not for consumer 3000 and 4000 series CPUs until December-ish.
When I updated my system I use arch BTW it had an upgrade for the amd Unicodeavailable. I don’t know if the fix was in there but maybe