Hacker News Reader

Comment by stephc_int13 | Hacker News Reader

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?

View on HN

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

Thank you! I was immediately reminded of that story when I read the article, but would never have been able to find it!

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.

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 source<->machine 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.

> 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.

Reply on news.ycombinator.com