Google researchers recently published proof-of-concept code demonstrating the ability to create malicious microcode patches on AMD processors from Zen 1 through Zen 4. This vulnerability would allow an attacker to arbitrarily alter the execution of virtually any instruction on a vulnerable processor.
The vulnerability, CVE-2024-56161, affects the most fundamental operation of a modern processor. Furthermore, the necessary microcode updates are only being distributed through BIOS updates from the corresponding OEM, not automatic OS update mechanisms. As a result, we expect many systems will not receive the necessary deliberate attention required to deploy firmware updates that address this issue.
Vulnerability Details
Modern processors have the ability to load microcode patches that alter the behavior of nearly any instruction. This capability is normally used to fix hardware bugs (including numerous vulnerabilities) in fielded systems. Valid microcode must be properly signed by the processor manufacturer, and the signature is checked when the microcode patch is loaded.
The vulnerability stems from an improper signature verification mechanism in AMD’s CPU ROM microcode patch loader. This security flaw enables attackers to inject malicious microcode into affected systems. Google’s proof of concept uses this to change the RDRAND instruction, which is used to generate cryptographic keys and other random values that are critical to cybersecurity. Instead of returning random data, they return the number 4. Every time. That is just an example of one possible impact. Nearly every assumption about how computers work is now up for grabs.
The issue affects AMD’s Zen architecture processors from Zen 1 through Zen 4, including:
- EPYC 7001 (Naples)
- EPYC 7002 (Rome)
- EPYC 7003 (Milan/Milan-X)
- EPYC 9004 (Genoa/Genoa-X/Bergamo/Siena)
Discovery and Disclosure
Google’s security researchers identified this vulnerability through their analysis of AMD’s microcode update verification process. The team discovered that the CPU uses an insecure hash function for signature validation of microcode updates. By exploiting this insecure hash, it is possible to generate microcode patches that match, which is demonstrated by their proof of concept. This microcode patch can be installed on production systems and will turn your cryptographically secure random number generator into a constant integer.
The issue was initially reported in September with the first AMD fixes being delivered under embargo to their OEM customers in mid-December. Additional details of the vulnerability will be released in March in order to provide time for vulnerable systems to be updated. We will all be eagerly awaiting more.
Detection and Mitigation
The Eclypsium platform has been updated to detect systems vulnerable to CVE-2024-56161. Our vulnerability assessment capabilities now include checks for affected microcode versions across the entire range of impacted AMD processors.
Recommended Actions:
- Scan devices with Eclypsium to identify vulnerable devices. Lock down code running on such systems as much as possible until updates have been verified.
- Update to the latest system BIOS.
- While Eclypsium will do this automatically, anyone can verify that updated systems are running the latest microcode version. This can be accomplished using head -n7 /proc/cpuinfo (refer to the field “microcode”) on Linux and reg query HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0 (refer to the field “Update Revision”) on windows. Compare this with the fixed microcode versions listed in AMD’s advisory. According to AMD, the latest microcode versions are as follows:
- Naples: 0x00800F12
- Rome: 0x00830F10
- Milan: 0x00A00F11
- Genoa: 0x00A10F11
- Some organizations may need to contact their device manufacturer to obtain firmware updates for specific hardware.
This vulnerability underscores the critical nature of supply chain vulnerabilities and why they are often particularly challenging to address. The low-level nature of this problem means that it undermines the many protections that the industry has developed in order to ensure the integrity of modern computers. In fact, it is difficult to put bounds on the nefarious capabilities presented by malicious microcode patches. When it comes to remediation, the fix is slowly filtered from the processor manufacturer to OEMs, to actual end customers. And all of this occurs in the context of a CVSS 7.2 vulnerability, which is likely to go unnoticed or at least not prioritized by many organizations.
It is critically important for organizations to maintain visibility into their infrastructure’s firmware security posture. The Eclypsium platform was created for this problem, and it continues to provide essential protection by identifying vulnerable systems and helping organizations validate their mitigation efforts.
