Zenbleed Is a Vulnerability That Affects All AMD Zen 2 Processors and Doesn’t Require Direct Physical Access

[Peter_Brosdahl]

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.

See full article...

 

[Uvilla]

I swear, when vulnerabilities read like this one all I can think is backdoor found by chance.

 

[Grimlakin]

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.

 

[Tempest]

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.

 

[Grimlakin]

Apparently AMD 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.

 

[Tempest]

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.

 

[Grimlakin]

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.

 

[Uvilla]

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.

 

[Tempest]

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.

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.