Live data from Hacker News

The Ken Thompson Hack

wiki.c2.com

11–20 of 46 posts

Re: The Ken Thompson Hack

#11

Surprisingly, it took until last year for someone to actually ask Ken for the code: https://research.swtch.com/nih

Thanks for the link. I had saved it for later reading, but didn't get around to doing it until now.

It's such a well-written article.

Here's previous HN discussion about it:

https://news.ycombinator.com/item?id=38020792

Re: The Ken Thompson Hack

#12
post #7

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 imple…

[deleted]

Re: The Ken Thompson Hack

#13
post #6

Clicked on the first Bell Labs link hoping to read the original and ended up on some VPN service's landing page. Sigh. :(

I preferred when link rot led to a 404 or site not found. I have recently been working with some stuff I wrote ~2004 and so many links are now dead. I've been giving archive.org a real workout.

Re: The Ken Thompson Hack

#15

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?

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.

Re: The Ken Thompson Hack

#16
post #15

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?

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?

Re: The Ken Thompson Hack

#17
post #15

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?

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.

Post reply on HN