Sounds like that one might have quite a bit of an Impact…
i don’t believe it …
Eh, you need physical access and it doesn’t survive a reboot. Doesn’t seem like much of a threat. Figures its the IME that’s vulnerable, though
The article is a bit confusing on that point but I came away with the impression that we are talking about firmware updates for the firmware that runs inside, not on, the main (/ real / x86) CPU i.e. the microcode.
I didn’t understand “write their own custom firmware” from the title - and it later on it suggests that that is not currently possible. This is an extraction of the encryption key (symmetric, using RC4) not the signing key (asymmetric, algorithm not stated, and only the public key would ever be able to be extracted). So you can analyze any existing firmware and, yeah, you could even literally write your own firmware but, as you can’t sign it, you wouldn’t be able to load it into the CPU and hence you can’t execute it. So writing it would only be fun for the purposes of running it on a microarchitecture emulator, or something like that.
If the attack goes undetected and it is an attack on a server then “not surviving a reboot” could mean surviving for years however.
It wouldn’t be so much a case of the “evil maid” as the “evil IT intern” etc.
While this does not allow to have signed microcode updates it opens the door to be able to reverse engineer Intel microcode updates.
See what makes them tick and how Intel is effectively patching or not vulnerabilities.
Yes, on 1st hand it should open the possibility to get an insight into the otherwise “obfuscated”/non-readable code. so possible holes could easier become obvious. On one hand that might help what they - in a negative way - call “hackers”, but on the positive side it also suddenly indirectly creates more transparency. So something more FOSSy/FLOSSy…