Microcode Patches Don’t “Fix” Your Processor
Your Processor Remains Exploitable
Intel recently released yet another microcode update to fix yet another speculative execution flaw in its processors. Ars Technica has a good writeup on the flaw if you’re interested in specifics.
However, I’m not concerned with this particular flaw. What I am concerned about is how it was fixed: via a microcode patch.
The common perception is that if you update your processor’s microcode, your processor is “fixed.” Well, it isn’t. As I explained in my posting Negative Rings in Intel Architecture: The Security Threats That You’ve Probably Never Heard Of, microcode updates are transient. That is, every time you reset your processor (e.g., reboot), you must reload your microcode patches. This opens avenues for exploiting a “patched” processor flaw.
In software, when you “patch” a program, you run the patch installer, and your software is “fixed” until the next bug is found, and it must be again patched. That’s not how microcode patches work. On Intel processors, microcode is stored in ROM on the processor, and microcode patches are stored in SRAM on the processor. Since a processor reset wipes SRAM, microcode patches must be reloaded after every processor reset.
Thus, to exploit a “patched” processor flaw, the attack becomes straightforward on most Intel systems.
- Get root privilege.
- Delete the microcode update file.
- Cause a kernel fault that forces a processor reset and reboot.
- Exploit the non-patched processor flaw.
Patching microcode is better than no fix at all, but only marginally better. A determined attacker will still be able to exploit the processor flaw. The microcode patch only thwarts script-kiddies.
So, like all things security, what you don’t know about is what’s going to come back to bite you later. Don’t think that because you’ve installed a patch for your processor bug, that the bug is now fixed. It isn’t. Architect your security accordingly.
Update
It was pointed out to me that if you have a system with UEFI flash and it has secure boot enabled, that it would prevent this type of attack. I concur. However, to install microcode patches then requires that the UEFI firmware be reflashed — a non-trivial update task.
Also, it has been my experience that the number of enterprise servers (the desired target for most attackers) enabling secure boot is minimal to non-existent in most organizations.
Please check out my Blog Introduction and Index to find other postings about what we are doing wrong in security and how we need to fix it.
