Hacker News Reader

Hacker News

Comment by zitterbewegung | Hacker News Reader

Full thread

zitterbewegung

A way to migtate this attack is here http://www.acsa-admin.org/countering-trusting-trust-through-... .

View on HN

Yes, I mention it in the post :)

Worth linking "diverse double-compiling" there or to some other resource, if I may make the suggestion.

For other interested readers:

a) html version of David Wheeler's dissertation: http://www.dwheeler.com/trusting-trust/dissertation/html/whe.... I read it over a week last month, and it made a big impression on me.

b) the HN discussion for the Wheeler dissertation: https://news.ycombinator.com/item?id=12666923

Good point, linked!

Well it looks like this answers the question I posited above. Very interesting work, surprised I hadn't seen it.

As I said there, Wheeler was exemplary for handling most of this right ahead of time. He gave credit to Karger for inventing the compiler subversion attack. He wrote the reference page on high-assurance FLOSS (for compiler verification) and high-assurance SCM (for repo security, esp distribution). He also wrote a cheat I gripe about in reproducible builds to give us something to work with if high-assurance methods get ignored. Any of his stuff on this subject is worth reading.

Here's his high-assurance and SCM pages:

http://www.dwheeler.com/essays/high-assurance-floss.html

http://www.dwheeler.com/essays/scm-security.html

Great writeup! And actually a fun idea for an intro to rust compiler internals. I'll be stepping through this in detail later.

It would be extra cool if you had a series and did this with Go as well :)

Thanks!

It shouldn't be hard, and I've played with the Go AST before. I ... could :)

This was sort of a bucket list thing though, doing it a second time is less fun :p And I don't have that much time.

Why don't you try? The technique explained in the blog post is pretty universal. Go has an AST too, and while the Folder abstraction doesn't exist in its codebase (as far as I know), you can still tweak the AST. In the case of Go it would be easier to do the injection during parsing. https://github.com/golang/go/blob/5c9035acc1e1540a564ea66000... would be a good entry point. https://golang.org/pkg/go/ast/ should help.

(I am not a Go compiler dev so there may be better entry points)

  > It shouldn't be hard, and I've played with the Go AST 
  > before. I ... could :)

Do it! :) Sadly the title is destined to be less fabulous than this one, but given Thompson's association with Go the motivating angle is obvious.

Ah yes - I forgot to mention: great title!

I think I might as well :) Time is also an issue for me though, but it's not a complete impossibility.

I appreciate the tips on starting points. Very interesting. If I do end up doing something like this I will give credit where it's due.

From that article:

> Simply recompile the purported source code twice: once with a second (trusted) compiler, and again using the result of the first compilation. If the result is bit-for-bit identical with the untrusted binary, then the source code accurately represents the binary

This sounds very familar to me. If I remember correctly, this is exactly what happens when you build GCC. GCC's 3-stage bootstrap process is well-known for a long time, as well as the decussion about whether this makes sense or is just paranoid.

It's nice to have this written down and analyzed throughly in a scientific paper, though.

I'll dig into the article, but out front there is something I don't understand. What is this second, trusted compiler? How did we get that? Why not just use that and its results, rather than vetting foreign compilers...? EDIT: Reading, but I think I'm having more questions, not less. The compiler source could introduces optimizations into the compiler binary's output that could be used to recompile the source again and get a _better_ binary right? The article speaks of compiling the source once with the the foreign compiler and then again with its results; but, on the trusted side it seems to be saying you just do one compilation and you don't compile the source again with the result of that compilation. Seems like you'd have to use the same measures on both sides before comparing binaries?

> a second (trusted) compiler

but… can we assume that any compiler is trusted?

We can't. It's why we need verifiable builds. C0, CompCert, KCC, and Simpl all have strong evidence of their ability to produce correct code from good C or specs of it. Checking that on local tooling plus an assembly build of it would be a start. It can build other things.

Or you can use the incremental approach I describe elsewhere in this thread.

Reply on news.ycombinator.com