Expert Says NSA Have Backdoors Built Into Intel And AMD Processors
eteknix.com
eteknix.com
Wikipedia tells me Steve Blank is "recognized for developing the Customer Development methodology, which launched the Lean Startup movement". That doesn't sound to me like the kind of expertise that would be useful for determining whether silicon chips contain backdoors.
If Steve Blank figured there must be something funny going on at Area 51, would the headline be "Expert Says NASA Have Aliens in Nevada"?
Do I ever agree with you on this one. I laughed when I read that as well.
I worked with Steve at a company he was VP of Marketing at. He is primarily a creative marketing and business guy and is good with the BS (I say that as a compliment by the way). While he does have technical abilities (just like I can put together some code) that is almost certainly not his area of expertise.
Of course what he is saying is possible. Sure. But anyone could have said that and trying to enhance the statement by referring to him as "one of Silicon Valleys leading experts" as if "he was on a high level team at Intel" or something is really just lazy you know what at work.
Next we will hear what Woz thinks about all of this.
You'd have to read the whole series, but his posts here give a good idea of his early background. It's pretty interesting, and it left me with the impression that he knows a thing or two about hardware. http://steveblank.com/secret-history/
I remembered this because he cited a few critical things he learned about Customer Development while at MIPS.
First sentence: "Experts think the NSA has hardware level backdoors build into Intel and AMD processors".
Second sentence: "one of Silicon Valleys leading experts, says that he would be extremely surprised if the American NSA does not have backdoors built into Intel and AMD chips".
Top notch journalism right here.
"There is a substantial design space in malicious circuitry; we show that an attacker, rather than designing one specific attack, can instead design hardware to support attacks. Such flexible hardware allows powerful, general purpose attacks, while remaining surprisingly low in the amount of additional hardware. We show two such hardware designs, and implement them in a real system. Further, we show three powerful attacks using this hardware, including a login backdoor that gives an attacker complete and highlevel access to the machine. This login attack requires only 1341 additional gates: gates that can be used for other attacks as well. Malicious processors are more practical, more flexible, and harder to detect than an initial analysis would suggest."
I have no opinion on whether or not there is a backdoor, but, here are some possible mechanisms.
1. Periodic SMI on steroids. Intel used to have a debug mode based on an SMI++ like mode, where the chip would periodically dump the entire state of the machine out to memory. That's not nearly as useful for debugging now as it was 15 years ago, but it could dump out compromising information to some buffer that your network card DMAs out.
2. RNG weakness.
3. Put the machine into ring 0, with no other changes.
4. Put the machine into ring 0, while transferring control to some address.
5. Access to the microcode patch mechanism.
It took me about 15 seconds to come up with those ideas (I thought of 4 when I wrote down 3). Regardless of what you think of the NSA, they have the of the best security people in the world. They can probably figure something out.
Any of these things could easily be triggered by a sequence of obscure instructions. There are plenty of userland instructions that are never used today. An arbitrary sequence of, say, 20 of them is likely to never be discovered even by brute force attack. If you're really worried, you can load up a few registers with some specific values, and now you've got a 192-bit keysize (or more, if you want).
If you want to keep it secret from the companies themselves, you're probably better off using a secret register key in some microcode instruction, since that would be relatively easy to surreptitiously sneak in after the official tapeout. Looking for a sequence of instructions wouldn't be technically difficult (I doubt the decoder/translator is on the critical path, but, Intel's might be custom, in which case it would be a lot of work to find spare space), but, it would be more work to sneak it in seamlessly. Then again, they almost certainly have free gates lying around so that post-silicon bugs don't require a full-layer tapeout to fix. You could write a program that edits the right mask layers to access those and patch your change in. But, if those actually get used for debug purposes, you'd lose the ability to make the change seamlessly, and, it's much more work than the first approach.
I suspect '5' would require restarting the machine, although you could design a mechanism that lets you hot-swap microcode. Doesn't seem worth it, though, considering how easy it is to compromise a machine if you control the hardware.
If it's possible, it would be a shame to loose the thread here.
Whether or not Steve Blank is qualified to make the observation seems like a Red Herring to me.
To me, this is the boring part—I'm much more interested in a) what they would collect, b) how they would identify it from the processor (if they didn't load software into memory), and c) how they expect to retrieve it. If they even attempted to use IP to communicate they would be caught immediately.
I say it is do-able and, if done right, very very hard to detect. Privilege escalations could be done in a small amount of obfuscated code. Implementing a sequence to trigger that is also do-able since there are usually many unused opcodes.
Also it is not entirely clear why, if such vulnerabilities do exist, why they would not have ever been used for anything, such as Stuxnet, because if they cannot be used for anything then what could be the point of having them? We're all familiar with the argument that the government will not disclose a hidden surveillance mechanism to catch a target that isn't "worth it" relative to the loss of secrecy, but if a suspected (however weak those suspicions may be) Iranian nuclear weapons program isn't worth it, then what, precisely, is?
Furthermore, is it politically feasible? The government has already seen leaks by the likes of Snowden and Manning, and this development would require even more time and effort and cooperation across teams of people who may not be entirely supportive of the far-ranging surveillance this would imply. It's one thing to backdoor a server, but to modify the architecture of the most advanced consumer products in the world is probably not going to be easy.
So I don't think it's impossible, but even the NSA is finite. They probably have better ways to spend their time.
IMHO, this is the best argument against such theoretical attacks. For more regular attacks against applications, I expect the NSA to be one of the most advanced organisations, since they can use the entire literature plus whatever they figure out on their own. But to have an entirely different attack vector, they would need to spend a similar level of research on this vector just to keep it competitive with open source research.
ad 5: Microcode updates can be installed on top of another, and there's a Linux driver for Intel at least (so they expect to still be able to install updates). They're not persistent though - after a reboot, they're gone.
In general: Intel has the Management Engine, a separate processor running its own multi-MB firmware and is required (otherwise you're system won't run for very long) and Intel-signed (so you can't replace it). It also has access to memory, USB, NIC and certain control over the CPU.
When it comes to your mechanisms, my guess is #4, but probably entering System Management Mode or Trusted Execution Mode (on TXT systems) - there are some things you can't access from ring 0.
As for hiding within the instruction set, x86 has prefixes and I doubt anyone tried redundant ones on all kinds of opcodes: something like "LOCK LOCK REPNE DATA32 DATA32 LOCK ADDR32 MOV $entrypoint, dr0;" might just do the trick. Or simply a long chain of non-sensical prefixes after which the CPU just expects a magic value and the entry point... x86 is known to accept 14 bytes of prefixes, so there's some space to hide special behaviour.
The backdoors you describe are local privilege escalations. How could a backdoor in a device on the PCI bus be constructed to call a backdoor in the CPU?
- The described timeframe for the transition to update-able microcode corresponds roughly with my vague memory of when the U.S. government started to give up (in practice, if not on paper) on "keeping the lid on" strong cryptography in the commercial and microcomputer worlds.
- We read that Lenovo is "untrusted". Are they piggybacking on such a feature -- which I've little doubt their more competent scientists and researchers would have thoroughly explored -- trace by trace, if and as necessary? If so, are Lenovo products then untrusted because a Chinese firm has control over their update process -- via BIOS or however else?
In other words, did... "Western" agencies provide part or all of the mechanism by which the Chinese are now supposedly compromising Lenovo PC's?
----
P.S. I'm now further put in mind of all the industrial et al. espionage that is now fairly well attributed to the Chinese government and agencies. Were details of this functionality one or more of the prizes they obtained?
I'm not saying this isn't possible. I'm just saying that there is absolutely no evidence provided that this has happened.
Shit claims like this discredit actual claims backed by evidence.
http://www.arrl.org/part-15-radio-frequency-devices
> Note: Computer terminals and peripherals that are intended to be connected to a computer are digital devices.
However to ignore the fact the these proprietary CPUs do not have additional opcodes or techniques to read its users work is ludicrous. Here are some prime examples from Intel:
http://software.intel.com/sites/manageability/AMT_Implementa...
http://blogs.intel.com/technology/2011/01/intel_insider_-_wh...
http://www.intel.com/content/www/us/en/architecture-and-tech...
AMD I have no evidence to support otherwise, but I would not doubt it.
Is there even literature that formalizes the possible types of CPU backdoors and attempts to layout means of defense? Let's assume there's some high level rootkit above any virtualization/signed code/etc. It seems like there's probably a continuum of how much effort is required to utilize this rootkit:
1. Sandboxed user code can control rootkit (through sequence of instructions or whatnot)
2. Raw network packets can control rootkit (what looked like a weirdly-fragmented http request contained extra data that instructed the rootkit)
3. Nondeterministic crypto primitives are actually deterministic (anything encrypted with them looks scrambled, but is easy to decrypt.)
4. Anything that appears to be a crypto instruction sequence is side-channeled into tiny correlated delays on network DMA.
In addition it seems like there's bounds on the complexity of this rootkit (surviving audits), and bounds on what/when detectable changes it can actually make (corrupting deterministic crypto functions on every CPU would be a non-starter).
I'm rambling on this because I think that even assuming widespread microprocessor backdoors, it seems that it should be possible to work our way to creating things that are actually trustable in certain situations. For example, much slower auditable processors handle all network communication and check results from the faster possibly-backdoored microprocessor computing only deterministic functions.
A much better way to do that would be an entirely independent CPU that has a copy of the bus, and can tristate it (so that when needed, it can feed the CPU any code/data it needs instead of main memory). If you do that, you don't have to run code on the target machine - you just have to make it see some data - e.g. by sending an email to that machine; no need for user interaction or code. You might even use public key infrastructure to make it impossible to tell which data it needs to see to activate.
And best of all -- only one layout guy needs to be any wiser, not the opcode people. Such an additional CPU, depending on complexity, might fit in a couple of thousands of transistors (the 8080, a general purpose 8-bit CPU that ran CPM, was all of 4500 transistors - virtually invisible in today's modern 1-2 billion chips).
Dutch article: https://www.security.nl/artikel/47135/1/De_onzichtbare_backd...
English summary:
Intel included a new CPU instruction called RdRand as of their Ivy Bridge architecture. This RdRand instruction produces random numbers generated by the chip itself. However the issue with this kind of random number generation, especially since Intel says it's cryptographically secure, is that it can not be audited or verified. Sure we can run statistical analysis on it, but we cannot tell the difference between true randomness and the output of AES-CBC. Nowadays the output is mixed with the existing entropy sources in Linux, but in closed source systems such as Windows and OS X we don't know how RdRand's output is used.
I also mention the potential consequences of such a bug, which are rather wide-ranging. If RdRand's output is used directly then we can assume: if you have an Ivy Bridge CPU or newer, all your ssl/tls traffic can be decrypted (it needs randomness to setup a session). If the server that generated the private key was Ivy Bridge or newer, all traffic to and from that server can be forged. Furthermore, things like TCP sequence numbers or DNS source port numbers could be predicted, allowing offensive capabilities as well as passive cracking of our traffic.
Again, I'm personally skeptical about all of this, but the potential consequences are quite bad, and it's not all that hard to hide their tracks... I can provide a theoretical proof of concept on demand. The only thing I have to guess at is whether the CPU can maintain a state between power cycles, that question is best left for others to answer. It would not have to be large though, a few bytes is all it takes.
Do Microsoft (i.e., Windows) updates really update the microcode? That sounds dubious to me, since it's a dangerous operation that could completely disable the user's CPU if it goes wrong (and I've seen Microsoft push buggy updates before).
Does anyone have any citations that would confirm that this statement is true?
In fact, I'm tempted to classify this article as 'complete non-sense', only believable by someone who has no idea what a CPU is. Given some of the comments about the Linux 'kernal' (sic), I'm not surprised this article made it to the front page of HN.
Doing this would be trivial with the microcode in modern x86 cpus, and while it would break (no longer trigger) if the netcode is updated (or even recompiled), that's rather rare, and cpu ucode can be updated too.
1. Not honor NX bit 2. Mess with RNG 3. Give constant ASLR on reboot
These alone can go a long way to compromising a system.
Say a popular chip A is well designed with low vulnerabilities. Say a less popular chip B actually has exploitable bugs.
In order to get a rival to use B, you would spread a rumor that you knew how to exploit A and see if you can nudge your rival to switch to using B.
A battery of tedious, slightly-differing benchmarks would be necessary to probe individual instruction, but I don't think it would be possible to evade this detection technique. It's simply too hard to make a backdoor operations on top of regular operations without padding the original instruction execution.
And there is not enough time in the universe to iterate through a 128-bit number, so you won't find the special case.
I don't actually subscribe to the "conspiracy theories" for the most part, including this one - really just making an academic point here. The whole backdoor theory, IMHO would have to rely on something in software to leverage the supposed backdoor.
However, the "sabotaged RNG" idea noted below is more plausible.
(Edit: Tuna beat me to the comment, I had not refreshed the page)
Then again NIST did once recommend a feeble RNG presumably so the NSA could break it with a RN skeleton key
This is probably BS but hopefully additional fear mongering promotes more open hardware projects. If you want to see terrifying insecurity reverse engineer any mobile baseband stack and processor its running in supervisor mode and everything is executable w/no NX bit
The code for SELinux that's in both GNU/Linux distributions and Android are all open source, and anybody can go and review the code or change it.
The existence of Linux on the desktop doesn't remove the threat of having NSA code built into your processor, but if you honestly believe SELinux is a backdoor then feel free to point out where in the source code the backdoor is located instead of spreading FUD for no reason. SELinux has nothing to do with what the article is talking about, that is, having malicious firmware baked into the processor at the hardware level.
That's tangential, though. More importantly, I expect NSA contributions to be poured over because the NSA isn't highly trusted, and it would make a great mailing list post to say "The NSA has a backdoor in our code here, here, and here."
Many eyes and a suspect contributor make all backdoors shallow.
Let's say they indeed decided to include something in the code submitted. It's an open source project, and it is a just matter of when someone will catch that. Once someone catch that, it gives them nothing but material evidence that they are up for something there. (and for that matter, it's not that every Linux users will have SELinux enabled to begin with.)
IMNO, hardware backdoor on the processors is a bit skeptical, though. I'm no expert on this but I don't know how easy to even exploit this type of backdoor without an assistance from the OS kernel. (Which MS might have implemented somehow.)
It's really a no-brainer to make such breakpoints that watch data in memory or registers that will be triggered by (e.g.) just processing a specific DNS packet.
They wouldn't need to purposely sabotage the linux kernel anyways it's like 15+ million lines of code they can easily review and find bugs as a homework assignment in first year internal classes on offensive exploitation.