Full Report
Microcode is code that runs during instruction execution. Much of this is in hardware, but some is small RISC instructions stored in some small storage on the chip itself. This makes bugs in the code, such as the famous Intel FDIV bug in 1994, patchable. The Microcode exists in on-die ROM but the patches are in on-die SRAM. The authors of this post were interested in how the patching process of these worked! Both Intel and AMD encrypt the patches to prevent reverse engineering and use digital signatures to prevent the loading of bad microcode patches. The update contains a lot of RSA key information, encrypted data of the patch itself and an array of information for where should be patched. To perform the upgrade, the following is done once the fix has been shipped: Software performing the upgrade will write the patch blob to MSR 0xc0010020 to start the microcode upgrade process. Copy the patch to the internal memory of the CPU. Checks for improper rollbacks and validates that this is indeed the proper RSA key. RSA PKCS #1 signature is decrypted using the RSA public key. The result is a padded AES CMAC hash of the patch contents. Signed hash content must match the calculated hash. Otherwise, the wrong data was sent. The CPU microcode patch version is updated. The verification for the patch signatures effectively uses RSASSA-PKCS1-v1.5 algorithm. The only difference is that a non-standard hash algorithm that is prone to collisions was selected. When hashing the data to sig, it's typically padded with a constant value. The recipient can use the public key to validate the signature. To break this, a complete break of RSA or the hash function would need to be found, making this secure. In sitautions where storage is an issue (like with on-die storage of a chip), a hash of the key can be stored instead. Then, when doing the signature verification, the public key is provided and hashed to validate that it's the same one as the one stored in the on-die storage. This system works because it's nearly impossible to find a collision between two plaintexts. The key vulnerability is that the hash function used is CMAC. Although this works as a Message Authentication code function, it does NOT function as a secure hashing function. That's not the goal of it! In practice, this algorithm looks like a CRC that XORs the bits. Since the verification of the RSA key is required for security, being able to submit our own RSA key via a hash collision would completely compromise the microcode update process. In practice, this only requires that we know the AES key of the signature, which has to be in every CPU - it's a bad assumption to make that this will be secret forever. To test this, they used old Zen 1 CPU example keys that were used up through Zen 4 CPUs. using this key, they could break the two usages of AES-CMAC: RSA public key and microcode patch contents. They were able to forge new public keys were generated the same hash as the authentic AMD key. In order to pull off this attack, a compensating block was needed with random data to align to 16 bytes. Since this is Microcode, it could cause crashes. So, they choose to attack the public key instead of the microcode patches themselves. To do this, they had to generate a second preimage of the public key. They generated a large list of candidate RSA public keys that collided with the expected public key. From there, they checked if the values were easy to factor, such as being divisible by 2. After some attempts, they found a suitable key! Ironically, to fix this, a microcode patch is performed to add a custom secure hash function. Using this bug, they were actually able to extract and reverse engineer previous microcode patches, such as the Zenbleed vulnerability. They created a tool that allows for the exploitation of this vulnerability on all unpatched Zen 1 through Zen 4 CPUs which will enable research into previously undocumented computer code. This blog post is pretty amazing. It required a deep understanding of cryptography and a ton of reverse engineering. The blog claims it will release a post on the reverse engineering aspect in the future.
Analysis Summary
# Research: Zen and the Art of Microcode Hacking
## Metadata
- **Authors:** Kris Brosch, Adam Zabrocki, and Alex Matrosov
- **Institution:** Binarly REsearch Team
- **Publication:** Binarly Blog
- **Date:** August 2024 (Addressing vulnerabilities in Zen 1 through Zen 4 architectures)
## Abstract
This research explores the security architecture of AMD’s microcode update mechanism. While microcode updates are traditionally protected by strong encryption and RSA digital signatures to prevent unauthorized modifications, the researchers identified a critical cryptographic weakness in how public keys are verified. By exploiting the use of a non-cryptographic hash function (AES-CMAC) for key validation, the team successfully performed a second-preimage attack. This allows for the injection of custom microcode, enabling the reverse engineering of proprietary CPU behavior and previously opaque security patches.
## Research Objective
The primary objective was to investigate the integrity and authenticity verification process of AMD microcode updates. The researchers sought to determine if the "Root of Trust" for microcode could be bypassed to allow the loading of custom, unauthenticated patches on modern x86 CPUs.
## Methodology
### Approach
1. **Reverse Engineering:** Analyzing the microcode update blob structure, including headers, RSA signatures, and encrypted payloads.
2. **Cryptographic Analysis:** Evaluating the specific implementation of the RSASSA-PKCS1-v1.5 verification used by the CPU.
3. **Collision Attack:** Identifying the use of AES-CMAC as a surrogate for a secure hash function (like SHA-256) when validating the RSA public key.
4. **Key Forgery:** Generating a mathematically "valid" RSA public key that produces the same AES-CMAC hash as the official AMD key stored in the silicon.
### Dataset/Environment
- **Hardware:** AMD CPUs spanning the Zen 1 to Zen 4 microarchitectures.
- **Microcode:** Authenticated update blobs provided by the vendor, including those for the "Zenbleed" vulnerability.
### Tools & Technologies
- **MSR (Model Specific Register) Manipulation:** Specifically 0xc0010020 for triggering updates.
- **Custom Cryptographic Tooling:** Used to generate RSA key candidates and perform high-speed CMAC collision searches.
## Key Findings
### Primary Results
1. **Cryptographic Misuse:** AMD utilized AES-CMAC—a Message Authentication Code designed for symmetric integrity—as a hash function for public key verification.
2. **Successful Forgery:** The researchers successfully generated a second-preimage for the official RSA public key hash.
3. **Complete Bypass:** By colliding the key hash, the researchers could sign their own microcode patches with their own private key, and the CPU would accept them as authentic.
4. **Retrospective Analysis:** The bypass allowed the team to decrypt and reverse engineer previous AMD microcode fixes (e.g., Zenbleed).
### Supporting Evidence
- The researchers demonstrated that the CMAC-based verification functions similarly to a CRC (Cyclic Redundancy Check), which is linear and susceptible to XOR-based manipulation.
- Verification that Zen 1 through Zen 4 shared the same architectural weakness.
### Novel Contributions
- The first documented method for "jailbreaking" the microcode update mechanism on modern AMD high-performance CPUs without needing specialized hardware probes.
- Discovery that hardware resource constraints (on-die storage) led to the compromise of cryptographic rigor.
## Technical Details
The vulnerability lies in the **Key-Hash-to-Key** verification. Because on-die ROM is too small to store the full 2048-bit RSA public key, the CPU stores only a hash of the key. Upon receiving an update, the CPU hashes the provided public key and compares it to the stored hash.
The use of **AES-CMAC** for this purpose is flawed because CMAC is not collision-resistant in the same way SHA-2/3 is. Using a "compensating block" (16 bytes of random-looking data), the researchers could manipulate the bits of a forged RSA key so that its final CMAC value matched the official AMD hash. This effectively "fools" the CPU into using the researchers' public key to verify the signature on a malicious patch.
## Practical Implications
### For Security Practitioners
- This research demonstrates that even high-assurance hardware signatures can be undermined by a single weak link in the cryptographic chain (the hash function).
- Possession of the AES key (used for CMAC) is a prerequisite for this specific attack; however, once leaked or reverse-engineered, the entire architecture becomes vulnerable.
### For Defenders
- **Firmware Updates:** AMD has issued microcode updates that replace the weak CMAC-based verification with a custom, secure hash function.
- **System Integrity:** Defenders should prioritize BIOS/UEFI updates that include these specific microcode revisions to prevent "evil maid" attacks or persistent malware at the microcode level.
### For Researchers
- Opens the door for "White Box" analysis of CPU internals, allowing for the study of how hardware mitigates side-channel attacks.
## Limitations
- **AES Key Dependency:** The attack requires knowing the specific AES key used for the CMAC calculation, which is embedded in the hardware.
- **Complexity:** Generating a colliding RSA key that is also mathematically valid (factorable) is computationally intensive.
## Comparison to Prior Work
Unlike the 1994 FDIV bug (a math error) or modern side-channels (Spectre/Meltdown), this research targets the **update mechanism itself**. It follows in the footsteps of "Intel TXE/ME" research but applies to the even deeper level of CPU microarchitecture.
## Real-world Applications
- **Malware Persistence:** Theoretically allows for the creation of "Mircocode Rootkits" that are nearly impossible to detect or remove via software.
- **Security Auditing:** Enables third-party researchers to verify that hardware mitigations (like those for Zenbleed) actually work as described.
## Future Work
- The authors intend to release a follow-up post detailing the specific reverse-engineering techniques used to extract the microcode logic once the signature was bypassed.
- Further study into the custom "secure hash" AMD implemented to fix this vulnerability.
## References
- Binarly: "Zen and the Art of Microcode Hacking" (hxxps://blog[.]binarly[.]io/zen-and-the-art-of-microcode-hacking/)
- AMD Security Advisories regarding Zen-series microcode updates.