Comment by striking | Hacker News Reader

Comment by striking | Hacker News Reader

Parent Full thread

> microcode-level rootkit

There's two ways microcode goes on Intel CPUs. The first is when it gets flashed in at the factory onto an OTP ROM. The second is when it gets uploaded to a block of internal RAM by your computer, every time it boots. That's why packages like this one (https://www.archlinux.org/packages/extra/any/intel-ucode/) exist.

One is set at the factory, one is set by your computer every time, once at boot, before the completion of boot. Also, it's very carefully signed, so even if you managed to put a bootkit before the OS boot, you would need to steal Intel's microcode key.

Microcode is not targetable. Few things at that level are. (A decent example of something that might be more targetable at that level is a hard drive controller. Less difficult but still not easy.) The amount of engineering needed to pull off an exploit that is "99.9% chance" unnoticeable, but still persistent, is much more than that of a "99% chance".

(I know nothing of AMD's CPUs and their microcode, but I'm guessing it's much of the same.)

First of all, thanks for writing this, since I did find the technical details quite interesting. But I don't think this puts microcode rootkits beyond the reach of a state actor. It puts them beyond the reach of a normal criminal attacker, which is actually my point.

Scenario 1: Supply chain interdiction. You don't need to target the CPU only after it has been manufactured and put into whatever you want to hack, you can start way earlier, including at the factory.

Scenario 2: Getting the signing keys from hardware manufacturers, including Intel, seems quite feasible for state actors. You don't even need hacking (I assume Intel's keys are kept air-gapped) or relying on secret court orders, plain old spycraft would probably do the trick.

That said, my argument can be rephrased to consider the hard-drive controller or other peripheral firmware rootkits instead, if you prefer and care only about scenarios where the rootkit must be delivered over the network to a clean system without attacking the CPU manufacturer.

Knowing the NSA got to the SIM cards manufacturer master keys, I wouldn't be surprised if they had Intel's key to forge microcode updates...

I wouldn't be surprised if the NSA worked with Intel to design their microcode update mechanism (selecting algorithms with advisements against classified breaches; generating key material and sharing between themselves; etc.) That would serve the NSA's interests in both their SIGINT and COMSEC roles at once.

The CIA took control of the SIM card manufacturer company through in-q-tel years before and willingly sold their shares just before the keys got stolen by NSA/GHCQ.

It was a big deal at the time known as "l'affaire gemplus" and it prompted the french government to set up the "Fonds stratégique d'investissement" or strategic investment fund, sort of a french in-q-tel.

Intel being a US company it is probable the US agencies have their ways with them.

As an attacker, you have a decent shot at doing UEFI/BIOS level exploits or even going after the Intel Management Engine.

This is why I run libreboot and I neutralized the IME by flashing my BIOS using SOIC-8 chip clips and a Bus Pirate.

I guess I'm paranoid.

Did you really "neutralize" the IME?

I guess you refer to a procedure as described in

https://hardenedlinux.github.io/firmware/2016/11/17/neutrali...

I would say what you did is to "neutralize" the ME firmware part in the flash BIOS. But this is only firmware that the ME loads additionally to load applications like e.g. AMT. The ME has it's own internal ROM containing it's very own firmware which is inaccessible and can not be modified.

So what you have is libreboot running on top of a still functional IME. All you gained is, that you got your BIOS of choice installed, and to remove some ME apps from the flash image. Correct me if I am wrong.

Reply on news.ycombinator.com