back
17 comments
Excerpt: "The result was 29 microcode operations including logic, arithmetic, load, and store commands — enough to start writing microcode code. The first microcode programs written helped with further discovery, naturally. But before long, they wrote microcode backdoors that triggered when a given calculation was performed, and stealthy trojans that exfiltrate data encrypted or “undetectably” through introducing faults programmatically into calculations. This means nearly undetectable malware that’s resident inside the CPU. (And you think the Intel Management Engine hacks made you paranoid!)"
Fortunately microcode updates are not persistent and need to be applied on every boot.
Additionally, modern microcode updates are both encrypted and signed blobs. Granted, it's of little use if Intel/AMD are playing the role of bad actor or if the signing and decryption mechanisms are bypassed somehow; but trying to load unsigned microcode by default will result in rejection.
It's worth noting that the analysis is on old AMD microcode precisely because AMD didn't use signed microcode for a long time and so they could create custom microcode to reverse engineer what it's doing.
I think that's 'unfortunately', and I think that such updates should require the movement of a switch or jumper to be activated. Obviously the 'hands off' and 'lights out' trends in the datacenter make such a requirement a non-starter but from a security perspective it would make good sense.
I think it's good. There's not much space in the microcode patch RAM, so hiding a malicious update like you would a root kit would be extremely difficult.
A stealth privilege escalation would be far more likely. Find a redundant, or unused bit, and...
It's too late to edit, but that's exactly what I would go for.
"There's probably not enough space for a meaningful exploit" is never a strategy that pans out.

Hardcoded signature validation can go a long way, but of course it really needs to be bulletproof, and also take e.g. downgrade protection into consideration.

An added physical switch, while more secure, is (as the previous commenter mentioned) so impractical, that it will more likely lead to less updating of vulnerable microcode.

One reason they do this is so bad fw can't brick an expensive CPU
Updates can be stored in the BIOS flash, so if you can program this you could theoretically update the microcode. The OS can also patch the microcode during boot.

The signature/encryption is still a problem, which might be why they are using older AMD K8 and K10 processors from 2007 which didn't have this security. Still, if the keys do leak out of AMD or Intel, this is a huge security hole.

What does “security hole” mean to you?
Ben Hawkes from Google Project Zero has an excellent blog post on Intel CPU Microcode:

http://www.inertiawar.com/microcode/

He even extracted and posted the RSA public keys used to verify the microcode. Though he later removed them, they're still available on the internet archive:

https://web.archive.org/web/20140403200048/http://inertiawar...

It’s a good investigation of the microcode update binary format, but doesn’t reveal anything about the microcode itself unfortunately.
How do they get around the crypto signature checks that the CPU does before loading a microcode patch?
From [1]:

"Most update mechanisms are protected by signatures or other cryptographic primitives. However there were some indications that older CPU models (until around 2013) do not have a strong cryptographic protection and thus would accept custom updates."

[1]: https://media.ccc.de/v/34c3-9058-everything_you_want_to_know...

I've been waiting over a decade(s?) for someone to pull this off. Reverse engineering this is a great accomplishment.