Back in the day, Ken Thompson described a rather scary problem with the way programming languages are compiled.
In summary, one could modify the C compiler so that, when it compiled some security-critical application like
sshd, it inserted a security hole. The pristine sshd sources, when compiled, would produce a vulnerable executable. But then to protect the modification to the C compiler from being found, one can use the same trick on the compiler - make it insert the bugs into sshd and into itself when compiled from pristine sources. Compile this compiler up, then test it on its original sources, and when it's all working OK, install it on a system (and the bad sshd) and remove the dodgy sources. Clear your
.bash_history and you're done
The thing is, this bug could then lurk in the system for decades. Until the source code for
sshd or the C compiler itself changes sufficiently for the 'patch' built into the C compiler to stop working, the bug will propogate every time the C compiler is recompiled. Even for other architectures and operating systems. If something like this was done to
gcc, then just about every Unix system out there would be vulnerable. Certainly all the open source ones, and MacOS X.
The problem is that spotting the bug would require manual examination of the binaries. And not with a disassembler compiled with
gcc, either - as Ken suggested, you can also make the compiler patch the disassembler to make it hide the work done by the compiler patch.
I wonder if the computers I'm using to write this have backdoors snuck in that way. I wonder if the computer you're using to read it has any. A well-funded adversary could go to great lengths to comprehensively much up
gcc, with intelligent pattern matching in the patch so that it will survive a fair amount of source code drift in the compiler before breaking, and cunningly spreading the effect of it over various wide-spread bits of code, so the overall effect isn't easily visible to somebody grovelling through the resulting machine code. GCHQ or the NSA, perhaps.
This is a contributing factor towards my desire to not base ARGON on top of
gcc. I'm designing HYDROGEN so that it can be implemented in machine code (can you even trust an assembler?) if necessary, and CHROME is to be implemented in HYDROGEN rather than in itself (metaprogramming doesn't count, since the results of the metaprograms aren't fed back into the same metaprograms).
There's still scope for vulnerabilities to be snuck in at the BIOS level, or with something in your bootstrap chain, but they can't self-propogate!