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

21–30 of 46 posts

Re: The Ken Thompson Hack

#21

Post by Veserv »

kwhitefoot wrote: post #17
Veserv wrote: post #15

Earlier quoted context omitted.

I mean, this class of attack is defeated as a matter of course in high reliability applications like aerospace. You just check the compiler output precisely corresponds to the compiler input. You need to do that anyways to prevent miscompilation errors in general (this class of attack is just intentional miscompilation), so it hardly counts as a nightmarish problem, just a annoying one.

> You just check the compiler output precisely corresponds to the compiler input. just is doing a lot of work there.

What do you want me to say? That is the work that you must do and that is routinely done. It is annoying, but it is not hard or special. Hardly a nightmarish problem if it gets solved routinely at scale across a entire industry.

Re: The Ken Thompson Hack

#23

Post by Veserv »

azornathogron wrote: post #16
Veserv wrote: post #15

Earlier quoted context omitted.

I mean, this class of attack is defeated as a matter of course in high reliability applications like aerospace. You just check the compiler output precisely corresponds to the compiler input. You need to do that anyways to prevent miscompilation errors in general (this class of attack is just intentional miscompilation), so it hardly counts as a nightmarish problem, just a annoying one.

How is this normally done? Manual review of machine code?

I do not work on verification directly, so I do not know the details. I believe at a high level you generally have a automated first pass which generates a sourcemachine trace. You then have multiple independent reviews validating the correctness and exhaustiveness of the trace.

Generally in these environments you build with optimizations off unless needed to ease this validation process as, obviously, you must validate the released/deployed version.

Re: The Ken Thompson Hack

#24

Post by nunez »

From the ACM paper [0]:

> Acknowledgment. I first read of the possibility of such a Trojan horse in an Air Force critique [4] of the security of an early implementation of Multics. I cannot find a more specific reference to this document. I would appreciate it if anyone who can supply this reference would let me know.

ofc the US Gov was behind this. Incredible.

[0]: https://dl.acm.org/doi/pdf/10.1145/358198.358210

Re: The Ken Thompson Hack

#25

Post by necheffa »

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…

So bootstrap in freestanding does make this kind of attack much more difficult to pull off, but with contemporary hardware, it does not fully prevent the attack.

What if the trojan is in microcode? No amount of bootstrap in freestanding can protect you here.

Re: The Ken Thompson Hack

#26

Post by kkfx »

A small side note: the website look like a classic web website, BUT if you run a privacy attentive WebVM [1] you get at first

[1] the monsters normally known as "browsers", witch happen to be something like `less`, `more`, `most` and so on, not much like a JVM "javascript required to view this site" while perfectly classic looking and modern looking websites works very well without js, if you enable js but keep third party contents restricted you get a "page does not exist"...

A critics just to say "please, if your audience is some tech savvy cohort, try to design things for them.

Re: The Ken Thompson Hack

#27

Post by ludocode »

necheffa wrote: post #25
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…

So bootstrap in freestanding does make this kind of attack much more difficult to pull off, but with contemporary hardware, it does not fully prevent the attack. What if the trojan is in microcode? No amount of bootstrap in freestanding can protect you here.

It is true that there are many layers of code below the OS level. UEFI for example is probably hundreds of thousands of lines of compiled code. Modern processors have Intel IME and equivalent with their own secret firmware. Almost all modern peripherals will have microcontrollers with their own compiled code.

These are all genuine attack vectors but they are not really solvable from the software side. At least for Onramp I consider these problems to be out of scope. It may be possible to solve these with open hardware but a solution will look very different from the kind of software bootstrapping we're doing.

Re: The Ken Thompson Hack

#29

Post by legobmw99 »

dwheeler wrote: post #22

For more, including information about the "Diverse Double-Compiling" (DDC) countermeasure, see my page: https://dwheeler.com/trusting-trust/

Question from reading the abstract: how does one acquire this “second (trusted) compiler” when you are genuinely suspicious you are facing an adversary using an attack like this one?
Post reply on HN