Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Ken Thompson Hack

wiki.c2.com

Post reply on HN
Print view View original

1–10 of 46 posts

Re: The Ken Thompson Hack

#5

Post by ludocode »

The team at bootstrappable.org have been working very hard at creating compilers that can bootstrap from scratch to prevent this kind of attack (the "trusting trust" attack is another name for it.) They've gotten to the point where they can bootstrap in freestanding so they don't need to trust any OS binaries anymore (see builder-hex0.)

I've spent a lot of my spare time the past year or so working on my own attempt at a portable bootstrappable compiler. It's partly to prevent this attack, and also partly so that future archaeologists can easily bootstrap C even if their computer architectures can't run any binaries from the present day.

https://github.com/ludocode/onramp

It's nowhere near done but I'm starting a new job soon so I felt like I needed to publish what I have. It does at least bootstrap from handwritten x86_64 machine code up to a compiler for most of C89, and I'm working on the final stage that will hopefully be able to compile TinyCC and other similar C compilers soon.

Re: The Ken Thompson Hack

#7

Post by kibwen »

stephc_int13 wrote: post #4

There is something nightmarish about this kind of exploit, and that is maybe why we've been collectively in denial for such a long time. How many supply-chain generated backdoors in the wild today?

Supply-chain backdoors are one thing, but the saving grace about the backdoors injected by trusting-trust attacks like in the OP is that they're quite fragile. If the shape of the expected target program changes sufficiently, then the backdoor will fail to propagate. And propagating the backdoor into programs that have yet to be written requires an effectively omnisicient adversary. As long as you have multiple implementations of a toolchain, you can repeatedly use them to compile each other in every possible configuration (and then use the outputs of those compilation steps as inputs to the same process, repeatedly) and then compare that the outputs are bit-for-bit identical until you reach a point where you're assured that either none of the compilers are backdoored or all of them would have to be.

So yes, they're scary, but there are countermeasures.

Re: The Ken Thompson Hack

#8

Post by legobmw99 »

stephc_int13 wrote: post #4

There is something nightmarish about this kind of exploit, and that is maybe why we've been collectively in denial for such a long time. How many supply-chain generated backdoors in the wild today?

One of my favorite short stories plays on the natural horror of this realization: https://www.teamten.com/lawrence/writings/coding-machines/

Re: The Ken Thompson Hack

#9

Post by pfortuny »

ludocode wrote: post #5

The team at bootstrappable.org have been working very hard at creating compilers that can bootstrap from scratch to prevent this kind of attack (the "trusting trust" attack is another name for it.) They've gotten to the point where they can bootstrap in freestanding so they don't need to trust any OS binaries anymore (see builder-hex0.) I've spent a lot of my spare time the past year or so working on my own attempt a…

Impressive work and truly necessary! Thanks for sharing.

Re: The Ken Thompson Hack

#10

Post by toolslive »

ludocode wrote: post #5

The team at bootstrappable.org have been working very hard at creating compilers that can bootstrap from scratch to prevent this kind of attack (the "trusting trust" attack is another name for it.) They've gotten to the point where they can bootstrap in freestanding so they don't need to trust any OS binaries anymore (see builder-hex0.) I've spent a lot of my spare time the past year or so working on my own attempt a…

really nice, and impressive work. However, I'm left wondering if a route via Forth would not have been a lot shorter.
Post reply on HN