Trust & Deception

Many years ago a guy named Ken Thompson wrote a paper called "Reflections on Trusting Trust," in which he revealed that he had written, just to prove a point, a bit of code for the C compiler, which would insert a backdoor into the login program for the operating system he also wrote.

It would also compile itself into a freshly compiled copy of the C compiler. He then recompiled the C compiler with itself, thus concealing the existence of his little backdoor from anything short of a reverse engineering of the C compiler.

This was, clearly, a phenomenally cool hack. It was creative, elegant, devious, and really drove home a point: Be careful whom you trust, from your OS to your C compiler on up.

I've recently run across two new articles that illustrate vulnerabilities that are related, although to my eye not as elegant or thought provoking.

The first one comes from SecurityFocus – "0wning Vista from the boot." The article is about VBootkit, a hybrid of the old boot-sector virus and a modern rootkit, this one designed for Vista. There are some very interesting comments here but I don't want to repeat the discussion of who did this work first.

The interesting thing to me is that the tool in question subverts the Vista boot process, latching itself into the MBR, and working the way through the boot chain, altering checksums on the fly to mask its presence. This particular implementation doesn't try to be particularly stealthy, and in fact advertises itself, but the fact remains that on 32-bit Windows, on a non-TPM PC, this is a truly viable form of infection.

Perhaps not the most obviously practical to install (requiring patch of MBR and reboot, which is not something that most systems will allow to go unnoticed), but it is fascinating to see how the various attempts within the OS loader to protect itself from modification fail because the trusted path – the MBR code – shouldn't in fact be trusted.

The second comes from eEye, in a recent issue of its Vice newsletter. It discusses (in great detail) the process of building a hacked firmware for gigabit NICs based on the Tigon2 chipset from Alteon. Alteon has done something most vendors don't do, and has released the source for the firmware to the public.

The chipset is based on a couple of MIPS processors, and lo and behold, you can pretty easily configure gcc to cross-compile some code for them. Take that, and the firmware source, and you’ve got an easy path into the kernel.

That's not exactly new, device drivers have always allowed kernel access if subverted, but this isn't talking about subverting the driver. It is talking about subverting the firmware itself. Try to find a current virus scanner that checks all the firmware on your system for viruses.

Now as it turns out, this particular chipset requires that the firmware be reloaded on each reboot, so this is less of a threat than it at first seems. It requires a major system compromise of a classical sort to exploit, and a simple reboot after removing offending firmware will resolve the problem.

But again, that's not what I'm interested in. People don't expect malware in a BIOS update. Neither do they expect a fully programmable processor to live on their NIC that allows an attacker to spawn a gdb session on their running Linux kernel.

Just as in Thompson's original article, these attacks point out threats that we've been vulnerable to for a while now. But in the second attack in particular, with the rise of significant and generalized processing capability on everything from hard drives to graphics cards to NICs, it seems to me that it is just a matter of time before we see attacks using these vectors in the wild. And, of course, if a buffer overflow in the vendor firmware on a NIC could be exploited to load a new firmware image... Certainly technologies such as TPM can help mitigate some of these threats, and they are becoming more common in business computers. However, we are always just pushing the trust back a layer. And in general we are out of luck. Any program that verifies other programs could itself be subverted. Thank you, Mr. Turing.

But we all know that we aren't in the business of eliminating vulnerability – we simply manage it. It may not be comforting, and it sure doesn't make a good corporate motto, but it doesn't hurt to be reminded of it now and again.

— Nathan Spande has implemented security in medical systems during the dotcom boom and bust, and suffered through federal government security implementations. Special to Dark Reading.