> It is probably harder to do this to GCC than to a proprietary compiler. > But there is no way to be totally sure.
The source code to the proprietary compilers is not published, so I think it's much easier to attack the GNU and OpenBSD tools than the proprietary ones. It doesn't matter how often the compiler source changes because the bug automatically copies itself into the output object code. Such a bug need not use source code to detect what program is being compiled. It would be better (and easier) to do pattern matching on the compiler's internal abstract syntax representation. This could automatically adapt itself when the structure of the target code changes. Unless the users immediately recompiled their OS kernel and all the system programs like login, getty etc., each time they recompiled the compiler, any back-doors that were put in the kernel would remain and "the penetrators" could just log in and make sure that the bug was still fully functional in the compiler binaries. The weak point is the distribution packagers. The focus of such an attack would be the debian and red-hat maintainers, and the OpenBSD guys, I would have thought. A compromise there would get into the source-only distributions as well. As I said, there is a solution, and instead of just opining what is the probability, without giving reasons for those opinions, we could actually show people how to reduce the probability to any required degree short of absolute certainty. So for example, if the NSA want to be sure they are secure, they can tell Congress they checked and the probability that there is a trojan in their systems is less than one in 2^-32, say. Ian
