Fully Countering Trusting Trust through Diverse Double-Compiling | Hacker News Reader

Fully Countering Trusting Trust through Diverse Double-Compiling

dwheeler.com

9 pointsmrduncan4 comments

I'm not sure I understand this; is this simply a method for detecting whether (for example) a gcc4.0 binary on your system is compromised, done by checking whether it matches the binary as compiled by a gcc4.0 compiled from source on another system?

I guess I don't see why this is worth a PhD; has nobody ever bothered to verify whether checking the binary against the results of a trusted compiler works? Did this guy contribute some measure of rigor that was previously missing?

No, it's for checking whether the compiler used to compile the compiler that produced the binaries on your system was compromised.

Intuitively, let's say I write a very early version of a (say) gcc, but insert code so that if the compiler detects that it's compiling a login program, it inserts logic into the binary so that "kt" can always login without a password. For this to survive beyond the next rebuild, the compiler also has to detect when it's compiling itself and insert the same logic. This 'Trojan horse' can survive as long as people keep compiling your compiler in itself, but is never detectable from looking at any later version of the source code.

So you need to trust each version of the compiler (assembler, linker, microcode) you are using all the way back in history. The claim of the PhD and the 2005 paper is that you can verify the integrity of a compiler using another compiler that you do trust, all the way back in history.

The apocryphal story is that Ken Thompson actually did this with an early Unix compiler. Here's his very short original paper:

http://cm.bell-labs.com/who/ken/trust.html

> The claim of the PhD and the 2005 paper is that you can verify the integrity of a compiler using another compiler that you do trust, all the way back in history.

Right. I'm wondering how this was sufficiently non-obvious to warrant a PhD dissertation.

The idea is that a compiler is, loosely, a self-reproducing program and is therefore in a position to propagate malware in a very subtle way - by modifying the binary version of future versions of itself.

From a security perspective, this is different from a compromised (say) Debian mirror because it's not a question of, "does this binary match the source I downloaded from?" but, rather, "does this binary do the right thing when I use it to compile my system?"

Think of it this way: you and a friend both compile GCC. But the native code which results is not necessarily the same - it depends on details of your machine and your existing compiler tools. So there is no way to say what "the binary for GCC 4.4.x on i686" should look like, so you cannot tell if your friend modified his compiler's source code just before compiling it. This is (sort of) the problem the paper is solving.

I am not an expert, but I hope this is clearer.

Reply on news.ycombinator.com