AMD "Zen 1" to "Zen 4" Processors Affected by Microcode Signature Verification Vulnerability

[AleksandarK]

Google Security Research team has just published its latest research on a fundamental flaw in the microcode patch verification system that affects AMD processors from "Zen 1" through "Zen 4" generations. The vulnerability stems from an inadequate hash function implementation in the CPU's signature validation process for microcode updates, enabling attackers with local administrator privileges (ring 0 from outside a VM) to inject malicious microcode patches, potentially compromising AMD SEV-SNP-protected confidential computing workloads and Dynamic Root of Trust Measurement systems. Google disclosed this high-severity issue to AMD on September 25, 2024, leading to AMD's release of an embargoed fix to customers on December 17, 2024, with public disclosure following on February 3, 2025; however, due to the complexity of supply chain dependencies and remediation requirements, comprehensive technical details are being withheld until March 5, 2025, allowing organizations time to implement necessary security measures and re-establish trust in their confidential compute environments.

AMD has released comprehensive mitigation measures through AGESA firmware updates across its entire EPYC server processor lineup, from the first-generation Naples to the latest Genoa-X and Bergamo architectures. The security patch, designated as CVE-2024-56161 with a high severity rating of 7.2, introduces critical microcode updates: Naples B2 processors require uCode version 0x08001278, Rome B0 systems need 0x0830107D, while Milan and Milan-X variants mandate versions 0x0A0011DB and 0x0A001244 respectively. For the latest Genoa-based systems, including Genoa-X and Bergamo/Siena variants, the required microcode versions are 0x0A101154, 0x0A10124F, and 0x0AA00219. These updates implement robust protections across all SEV security features - including SEV, SEV-ES, and SEV-SNP - while introducing new restrictions on microcode hot-loading capabilities to prevent future exploitation attempts.



View at TechPowerUp Main Site | Source

 

[_roman_]

Please link those CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-56161

And the related documents: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html

Check the time frame: September 25, 2024 - March 5, 2025

 

[AleksandarK]

Please link those CVE: https://nvd.nist.gov/vuln/detail/CVE-2024-56161

And the related documents: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-3019.html

Check the time frame: September 25, 2024 - March 5, 2025

In the source, adding link in text for easier access.

 

[ncrs]

A very interesting side-effect from this patch is that Rome and Naples (EPYC 7001 and 7002) will lose the ability to update microcode at runtime:

Microcode cannot be hot-loaded after updating to this PI version

This means that only BIOS updates will be able to deliver future microcode updates to those CPUs which somewhat limits potential security guarantees as some vendors have a spotty record with timely BIOS releases (looking at you here, ASRock Rack).
For Milan and Genoa (7003 and 9004) a similar, but more manageable issue occurs. This particular fix has to be delivered by the BIOS vendor or any future microcode update at runtime will fail (probably because the cryptography changes).

 

[AusWolf]

So basically you need to perform a microcode (BIOS) update with malicious code in it to execute it? I wonder how it got such a high severity rating.

 

[ncrs]

So basically you need to perform a microcode (BIOS) update with malicious code in it to execute it? I wonder how it got such a high severity rating.

No, executing a runtime microcode update is enough. This can be done for example from Linux with root privileges.

 

[Onasi]

As always with these vulnerabilities, they sound scarier than they are and completely irrelevant for home users. If someone has a full physical access to a PC with a local admin privilege… yeah, you have multiple problems to worry about all at once. For enterprise this is obviously a different issue.

 

[ncrs]

As always with these vulnerabilities, they sound scarier than they are and completely irrelevant for home users. If someone has a full physical access to a PC with a local admin privilege… yeah, you have multiple problems to worry about all at once. For enterprise this is obviously a different issue.

Physical access isn't required, local administrative access is enough. That can be theoretically achieved for example by visiting a website with a vulnerable browser and chaining another vulnerability to exploit the host system. This is a complex attack so the severity rating is only 7.2 out of 10 (while it is "high" it's a low high ). As you wrote it's not something a normal PC user should worry about.
I am curious if there's a difference between Ryzen and EPYC microcode loading since Ryzens also can perform runtime updates. Will there be a separate AGESA update to address this?

 

[AusWolf]

Physical access isn't required, local administrative access is enough. That can be theoretically achieved for example by visiting a website with a vulnerable browser and chaining another vulnerability to exploit the host system. This is a complex attack so the severity rating is only 7.2 out of 10 (while it is "high" it's a low high ). As you wrote it's not something a normal PC user should worry about.
I am curious if there's a difference between Ryzen and EPYC microcode loading since Ryzens also can perform runtime updates. Will there be a separate AGESA update to address this?

But something has to be executed locally on your PC... something you downloaded or obtained from other sources, something with a microcode update in it. Right?

I mean, some basic browsing skills (not clicking on suspicious links, not downloading anything unverified, etc.) should mitigate the issue, I suppose.

 

[ncrs]

But something has to be executed locally on your PC... something you downloaded or obtained from other sources, something with a microcode update in it. Right?

Yes, but "downloaded" in this context doesn't necessarily mean conscious user action.

I mean, some basic browsing skills (not clicking on suspicious links, not downloading anything unverified, etc.) should mitigate the issue, I suppose.

Unfortunately this often isn't enough. There have been instances when browser exploits required no user interaction other than visiting a site. Malicious ads are also a vector of delivery so even if you're careful and visit only "safe sites" you can be infected. Web browsers are extremely complex pieces of software that face constant attack attempts. You can take a look at a few of 0-day vulnerabilities in Chrome just for the first half of 2024. It's an ongoing cat-and-mouse game. Keeping your browser automatically updated mitigates most of those issues, but by no means makes you immune.

On the other hand this particular AMD issue is so specific that the risk to normal users is almost 0. I doubt anyone would bother creating a widespread attack for it, but targeted attacks by state-level agencies are another matter

 

[AusWolf]

Yes, but "downloaded" in this context doesn't necessarily mean conscious user action.

Unfortunately this often isn't enough. There have been instances when browser exploits required no user interaction other than visiting a site. Malicious ads are also a vector of delivery so even if you're careful and visit only "safe sites" you can be infected. Web browsers are extremely complex pieces of software that face constant attack attempts. You can take a look at a few of 0-day vulnerabilities in Chrome just for the first half of 2024. It's an ongoing cat-and-mouse game. Keeping your browser automatically updated mitigates most of those issues, but by no means makes you immune.

On the other hand this particular AMD issue is so specific that the risk to normal users is almost 0. I doubt anyone would bother creating a widespread attack for it, but targeted attacks by state-level agencies are another matter

In that case, let's hope that motherboard manufacturers come out with updated BIOSes with the new microcode soon enough.

 

[JustBenching]

At it again, sacrificing safety for cheating on performance metrics.

Performance regressions incoming.

 

[AnotherReader]

Physical access isn't required, local administrative access is enough. That can be theoretically achieved for example by visiting a website with a vulnerable browser and chaining another vulnerability to exploit the host system. This is a complex attack so the severity rating is only 7.2 out of 10 (while it is "high" it's a low high ). As you wrote it's not something a normal PC user should worry about.
I am curious if there's a difference between Ryzen and EPYC microcode loading since Ryzens also can perform runtime updates. Will there be a separate AGESA update to address this?

Yes, it's surprising that AMD's note only lists EPYC generations, not Ryzens.

Performance regressions incoming.

I doubt that this would cause a performance regression as the fix won't disable or slow down a critical part of the processor's microarchitecture.

 

[ncrs]

Yes, it's surprising that AMD's note only lists EPYC generations, not Ryzens.

I have a suspicion as to why. This particular security bulletin is about SEV (Secured Encrypted Virtualization) which is an enterprise feature absent from Ryzens and even AM5 EPYC 4004.
The microcode runtime update vulnerability is probably also present in Ryzens, is definitely present in Ryzens since Google's PoC worked on a laptop chip, but not disclosed by AMD yet. I guess it will be added to AGESA at a later date.

 

[Count von Schwalbe]

At it again, sacrificing safety for cheating on performance metrics.

Performance regressions incoming.

This doesn't seem to be related to any part of the actual data processing, unlike speculative execution side-channel attacks. Just another security hole in update process code. I can't see how it would affect performance in any way to straight up delete that functionality, let alone patch it.

 

[_roman_]

As always with these vulnerabilities, they sound scarier than they are and completely irrelevant for home users.

I agree on this CVE. Generic I disagree.

If understood correctly what I saw hours ago it is about epyc processors - or milan whatever they call these server cpus.

I wondered if my Ryzen is affected or not.

But something has to be executed locally on your PC... something you downloaded or obtained from other sources, something with a microcode update in it. Right?

I'm very happy that certain package manager use now keys to verify downloads and checksums to verify downloads. A big improvement for a few years. Windows can not do that afaik. You download something and hope that computerbase.de/download has a clean download for software vlc, microsoft windows, intel driver, and so on. Let's trust the windows software download server and companies

This is a generic statement that I have to download every single windows 11 pro 24h2 software by hand, store it and execute the installer by hand.

powershell scripts which install modules which only nerds know about like winget do not count for the usual consumer.

browser exploits

i doubt those websites like pcgameshardware.de to name someone who is not here - check every single advertisement file by a human person.
I'm not implying using an adblocker may be a security enhancement feature.