A Google Information Security researcher named Tavis Ormandy has discovered a major vulnerability that affects all AMD Zen 2 CPUs. Tavis worked alongside fellow colleagues Eduardo Vela Nava, Alexandra Sandulescu, and Josh Eads to discover and analyze the bug that was found during routine hardware testing. Zenbleed is a vulnerability that is one of the more unique ones to be discovered in recent years in that it does not require physical access to the targeted system. An attacker is capable of using javascript via a webpage to retrieve sensitive information, including encryption keys and password logins from the CPU. Zenbleed is so invasive in its ability to allow data extraction that information can be obtained from all software using the CPU including virtual machines, processes, and sandboxed environments.
Per Tavis Ormandy:
“The bug works like this, first of all you need to trigger something called the XMM Register Merge Optimization2, followed by a register rename and a mispredicted vzeroupper. This all has to happen within a precise window to work.
We now know that basic operations like strlen, memcpy and strcmp will use the vector registers – so we can effectively spy on those operations happening anywhere on the system! It doesn’t matter if they’re happening in other virtual machines, sandboxes, containers, processes, whatever!”
The news gets worse as the researcher explains that after a bit of work, they were able to create an exploit capable of extracting 30 kb per core, per second. Furthermore, as stated, Zenbleed affects all Zen 2 processors, including data center processors.
- AMD Ryzen 3000 Series Processors
- AMD Ryzen PRO 3000 Series Processors
- AMD Ryzen Threadripper 3000 Series Processors
- AMD Ryzen 4000 Series Processors with Radeon Graphics
- AMD Ryzen PRO 4000 Series Processors
- AMD Ryzen 5000 Series Processors with Radeon Graphics
- AMD Ryzen 7020 Series Processors with Radeon Graphics
- AMD EPYC “Rome” Processors
The good news, and yes there is good news at the end of this dark and very scary tunnel, is that AMD has already been rolling out microcode updates to mitigate this vulnerability. Zenbleed’s technical name is CVE-2023-20593 and AMD has published a bulletin about it which includes details for updates already available as well as expected timelines for others that are planned to be rolled out by the end of 2023.
Per AMD:
“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.”
Tom’s Hardware has provided extensive lists of affected processors which include desktop, mobile, and server CPUs, along with AGESA version updates and release schedules. Tavis also provided a software workaround for those who are currently unable to use a microcode update in his post about Zenbleed. Tavis does speculate that the workarounds could potentially impact performance but AMD has not yet said if this is true.
Per Tavis Ormandy:
“Workaround
It is highly recommended to use the microcode update.
If you can’t apply the update for some reason, there is a software workaround: you can set the chicken bit DE_CFG[9].
This may have some performance cost.
Linux
You can use msr-tools to set the chicken bit on all cores, like this:
wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))
FreeBSD
On FreeBSD you would use cpucontrol(8).
Others
If you’re using some other operating system and don’t know how to set MSRs, ask your vendor for assistance.
Note that it is not sufficient to disable SMT.”
Discussion (8 replies)
Join Discussion →I swear, when vulnerabilities read like this one all I can think is backdoor found by chance.
That's big but being patched. I wonder if anyone is doing some DB and Application level performance testing for before and after the MC update to see what the impact is.
Thanks for posting about this, and also linking to the original source article.
Apparently AMD unexpectedly published patches earlier than the embargo date that was agreed upon. Not cool.
In what world is patching a vulnerability BEFORE it is published a bad thing? I think you miss the whole idea of agreed embargo dates for bug hunters. It's to give the business a chance to remediate the issue before releasing it to the wild for broader exploitation.
I mean really... I struggle to see where that is a bad thing.
Because the researchers need to inform and coordinate with OS distributors so that they have time to prepare. There are more parties involved than just AMD.
This is noted by the researchers themselves in the README.md included with the PoC (the zenbleed-v5.tar.gz archive linked from the original source article), which was the basis for my comment:
### 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.
I still fail to see the issue here. AMD made a fix and published it. Software vendors need to do what with AMD's fix other than make it part of their driver set that is a redistributable of the AGESA set from AMD?
I'm still left scratching my head. So AMD isn't allowed to publish a fix until the bug hunter decides AMD can do it? Makes it sound like the bug hunters want time to exploit the vulnerability before it is remediated.
I guess meaning they didn't pass on the patches secretly for a while as long a time as agreed with relevant players? Is that what you (tempest) mean? Yeah that's a bit of foot shooting there, unless they were doing so and getting feet draging in response, so in order to not allow others to say, ' well we didn't get anything on time from AMD, blah blah blah' AMD just said screw it, patches are out, ask the software people. Likely though, AMD didn't communicate internally, perhaps they are working from home still, and someone just released it.
Security embargoes have been a matter of debate for decades. The issue is that when multiple parties are involved and one of them breaks the embargo by publishing a security fix earlier than agreed, the vulnerability can become known to attackers before others have had time to prepare patches, workarounds, or whatever for release. Coordinated release dates can reduce the window of time that attackers have available to exploit vulnerable systems, but that is dependent on the vulnerability remaining unknown to potential adversaries. The longer the embargo, the greater the risk. In the ideal scenario, all vulnerable systems would be patched as early as possible and at exactly the same time.
It doesn't appear that AMD's actions are the cause for global panic. I just commented that it was "not cool" to have apparently broken whatever agreement they had made. I don't see why that is so confusing. I edited my post to include the word "unexpectedly", if that makes the issue more clear.