Hiding Backdoors In Hardware 206
quartertime writes "Remember Reflections on Trusting Trust, the classic paper describing how to hide a nearly undetectable backdoor inside the C compiler? Here's an interesting piece about how to hide a nearly undetectable backdoor inside hardware. The post describes how to install a backdoor in the expansion ROM of a PCI card, which during the boot process patches the BIOS to patch grub to patch the kernel to give the controller remote root access. Because the backdoor is actually housed in the hardware, even if the victim reinstalls the operating system from a CD, they won't clear out the backdoor. I wonder whether China, with its dominant position in the computer hardware assembly business, has already used this technique for espionage. This perhaps explains why the NSA has its own chip fabrication plant."
Lojack for Laptops... (Score:3, Informative)
A good example of this is Lojack for Laptops to see about having stuff in hardware be able to keep a program installed and hidden.
Re:Not bad but.. (Score:5, Informative)
1) First Intel (after initially responding poorly to the bug) fully recalled the product without question. If you had a processor in question, you could ask for and recieve a replacement. Please see http://en.wikipedia.org/wiki/Pentium_FDIV_bug [wikipedia.org]
2) The flaw was caused by a bad division lookup table, not the mathematical nuance of binary logic gates. What I think you are trying to describe is the fact that floating point numbers are not percise, and you never compare them directly, only compare if they are within a small delta of each other.
Re:how do you hide it from QA? (Score:3, Informative)
i've worked for Uncle Sam for 9 years. the government buys their IT crap from CDW and the same companies corporate america buys from. one time i tried to order laptops direct from Dell and it took months of getting special permission to get it done.
and the government buys their IT crap little by little like everyone else. a PC here, a server the next month. a few servers and storage a few months later when there is money. one time they bought layer 2 switches in the 1990's which sat around for over a year because there was no money for the contract to install them. at the end of the year a lot of the "unspent" money gets spent on wishlists and you may have hardware bought one year and the labor paid for the next year
Re:Not bad but.. (Score:5, Informative)
Diverse Double-Compiling counters "Trusting Trust" (Score:5, Informative)
add special private plants to the mix (Score:3, Informative)
there are also a very limited number of secured chip fabs in the US, plants in which security is so well controlled that they are licensed to produce sensitive silicon for the government. IBM's fab in North Burlington is known to be one of them. you used to find all sorts of custom logic with IBM on the top in things like ethernet cards and video chipsets and the like. no more. no capacity.
Re:NSA Fabrication Plant... (Score:1, Informative)
Government fab plants and paying premiums for every part. People shouldn't bitch about taxes and deficits unless they are willing to cut defense spending also.
Re:proprietary firmware (Score:1, Informative)
Why so snarky?
Are you just naive, or English is not your first language?
The GP was saying "we" as in "other than me or the people I know around me". The parent than pointed out that the GP has an Ubuntu address, Ubuntu is believed (justly or not) to not contribute much to the Linux community and specifically have a history of making grand proclamations about what people other than them need to be doing to improve the Linux experience (whether or not they are right doesn't matter, the Linux community is built of anti-establishment types who resent being told what they should do regardless of justification).
Re:Diverse Double-Compiling counters "Trusting Tru (Score:2, Informative)
Yes. In the purest form of DDC, you would need to implement a compiler, an OS to host it, and possibly the hardware to run that OS, from scratch. The saving grace is that it doesn't have to be a very good compiler, or a very fun OS to use, or a very fast computer. As long as it generates correctly compiled code, you can use it to compile your good compiler.
Meanwhile, on your Dell running Red Hat, you compile your good compiler (we'll just say it's GCC) using your existing copy of GCC. Now you've got two second generation compilers. Their internal code should differ drastically, but their output should be identical.
Use each of them to compile GCC once again, and you should have two identical executable blobs.
In a less thorough version of the same exercise, you can just use two compilers that don't share a pedigree, and hence are unlikely to be infected with the same compiler-resident bug. Even in the strict form, however, you "only" have to generate a working compiler, not a highly optimized and highly optimizing compiler.
It's not like it could be a weekend project for me, but it also doesn't mean duplicating 20 years of development work. You still end up with GCC (or whatever), and you add the ability to trust your code at the price of developing a compiler.