It is brittle but an evil compiler can account for that by attempting to compile the hacked program and falling back to real compilation if it gets a compilation error. It could even try downloading an update and try recompiling, but this introduces other ways it can get caught.
Yeah I discuss this at the end of the post. Will link it here:
The current best known defense is Diverse Double-Compiling (DDC), introduced by David Wheeler in 2009. To briefly summarize DDC uses different compilers of the same language to test the integrity of a chosen compiler. In order to pass this test the attacker must have modified all the selected compilers beforehand to insert backdoors into each other, which is a decent amount of work. DDC is a good idea but it has 2 shortcomings that come to mind. The first is that DDC requires all selected compilers to have reproducible builds, meaning that each compiler always generates the exact same executable given the same source code. Reproducible builds aren’t very common because compilers by default include things like timestamps and unique IDs in their builds. The second shortcoming is that DDC becomes less effective for languages that only have a few compilers. Also DDC can’t even be applied to newer languages like Rust with only one compiler. In summary, DDC isn’t a silver bullet and the Thompson attack is still considered to be an open problem.
> This is something that could easily occur with scripting languages, backend systems, open source, closed source, etc. Basically any black-box system that takes in some input could pre-manipulate the input yielding an unknown/unexpected output.
IMO thats why it's a scary attack. It's a really simple idea and there are so many ways to apply it
Discusses the history of computing and the rise and fall of tech companies as the industry changed. It's old but worth it imo
https://www.youtube.com/watch?v=MNVbmzVCyLU