Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

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:

1. Software performing the upgrade will write the patch blob to MSR 0xc0010020 to start the microcode upgrade process.
2. Copy the patch to the internal memory of the CPU.
3. Checks for improper rollbacks and validates that this is indeed the proper RSA key.
4. RSA PKCS #1 signature is decrypted using the RSA public key. The result is a padded AES CMAC hash of the patch contents.
5. 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.