Hacker News new | ask | show | jobs
by rossjudson 2051 days ago
All you need is to be able to influence the behavior of the build system at runtime. If you have that, you do not need access to the source code, and you do not need to check anything in. This includes scenarios where the tool chain itself is checked into the source control system.

Ken Thompson described this a long time ago: https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html

At runtime, you alter the build system to notice if a new compiler binary is being built. If so, inject code that, from then on, invisibly "injects the injector". Once you've shifted to this new compiler, the compiler binary itself is the attacker.

Since you have an injector, you can put other types of detections and alterations in...like watching for the compilation of the initialization of a Solarwinds DLL. Then you inject in what you need. No source code is involved.

There are probably lots of ways of getting around this, but unless you're actually looking for it, you won't see it.

2 comments

Successfully pulling off such an attack, of course, is quite difficult.
Nothing is difficult if theres a good reason to do it and you have money and time to do the attack :)
This is really interesting - really seems to be an argument in favor of all code being open, shared source - along with deterministic builds, it would be easy enough for any organization to build Orion themselves and verify they get the correct build hash. Or if there was a disagreement in hashes between SolarWinds and their imagined community, it would serve as a red flag.
This code was added to the Solar Winds source codebase, if I read the article correctly. No check in the world is going to catch it if it's actually in the base code.

Carefully compiling a corrupted program doesn't fix it.