CPU Backdoors

CPU Backdoors
danluu.com

I think a chip backdoor could also be based on information leaking rather than executing arbitrary code.

The steps would be: 1. Identify critical info, like crypto keys, from heuristics. This means keeping a special buffer, since you don't know at the beginning of an RSA operation that it's an RSA operation. The heuristics are not perfect, of course, but work with standard apps like Firefox, GPG and Outlook.

2. Exfiltrate the info. Via spread-spectrum RF, timing jitter in packets, or replacing random numbers in crypto. The article implies that since OSes and apps mix the hardware RNG with other sources, there's no point in subverting it. But the CPU can recognize common mix patterns, like in the Linux kernel, and subvert the final output.

In this case the output entropy is good, but also leaks some secret to a listener who has the right keys.

2. You don't need access to the box. You just get the target to load a site with JS that sets x and y to those specfic values and adds them, and then adds zero to some address you want to execute (which you can aim to be shellcode in a JS string or something, but even if not there are a million tricks you can use to execute arbitrary code if you can run code at an arbitrary address).

3. Assuming the JS engine compiles sanely, you now have a way to control any computer and make it do anything via some JS on any web site. Ring-0 can totally bypass all virtualization and even the OS itself.

And this exploit is so simple and powerful that everything else is a waste of time. No need to use statistical and entropy tricks to leak keys. You can own any computer with JS on a web site and steal anything you want from memory, including keys. And you can probably do this without the target noticing anything.

in terms of understanding/mitigating these types of threats, i wish an open, crowdfunded project to reverse engineer the contents of intel's microcode updates existed to the point they were understandable by the tech press.

i also wish an easy-to-use package for blacklisting cpu-based and crypto-related kernel modules (like aes-ni) existed for a broad range of processors..

and of course only somewhat relatedly, i continue to wish the man page for random(4) would be rewritten in light of the risk of these types of backdoors.

For example, it would be difficult to make an instruction like fyl2x or fadd cause a privilege level change. The reason is that floating point instructions are executed on a separate unit (the FPU), with a separate decoder. This unit would not have the means to communicate back information such as "change privilege level" (normally it can only signal floating point exceptions, and other than that its only output is on the floating point registers). It would make more sense to encode the backdoor on an illegal opcode, i.e. an opcode that under normal conditions would generate a UD# exception, but with the correct values in the registers it would trigger some undocumented behavior.

Another question is how to hide this backdoor in the microcode. Presumably, at some point someone might stumble upon the backdoor and ask around about it. If the backdoor depends on some "magic values", it would be relatively easy to spot just by looking at the microcode.

There's also the point that the author mentioned of "fixing" the processor at some point during the production process. I don't think that the author understands the way mass production of microchips works. It's very much not possible to do something like this while keeping the production price on the same level (or someone noticing this extra step in the production process).

All in all, it sounds much easier to find security bugs in other parts of the system.