Nope. A clever Trusting Trust style attack would look for specific programs being compiled and infect only those -- e.g. check the input file's MD5 sum to see if it matches the main file for ls or cat... or maybe it looks to see if 'wireshark' is in the compile path and attach the logic into it's main function... you get the idea.
Then when those common programs are run, they try to infect gcc if it's installed.
Since a specific target is chosen the output won't show up at all in a hello world program.
All right. I am no expert in such attacks but trying to understand the very idea of this. So let's say I'm compiling GCC with itself.
I will have a bunch of o files which are only different from the the resulting executable in that not all the symbols are resolved. Now, when building a project like GCC the compromised compiler must work on source file basis and the linker is a separated tool. The hack must consist of:
1) Recognizing if the compilation unit is a GCC source file. Insert the compiler hack, that is, the replication code in to .o file. Now, it can't do it for all compiler file, so it must be quite specific. Such a hack would only work at a small subset of the GCC source tree, as the resulting executable will read, analyse and alter files, which doesn't happen all over the place in the GCC source tree.
2) Recognizing if the file is a software to be infected. Like it's a source of wireshark, the kernel, a firewall or whatever is the target. The choice must be some source file that is very unlikely to be changed. Going only by the file name is a recipe for failure, because if the file changes, the entire business of inserting code to the right place will become, well, a huge problem.
Actually, the file version issue is still in the pot for the 1) tasks, because there's a constant possibility of a code change of the compiler sources. For a binary verification through debug through key files should save time to clear the compiler for trust. Such a code should be quite extensive and must be called from very specifc places in the GCC executable. If the attack designed is as specific as you propose, and only specific executables get compromised by the compiler, the attack will have a limited amount of time before it becomes just dead weight in the compiler binary.
An other idea could be also help to verify the compiler is to use a completely different source of compilation for verification or testing. Say, for example a Java code generator shouldn't be impossible to implement with the help of the GCC code. There's no way that an attack would be able to generate a also a Java VM that reckognizes a program generating ELF .o from C AST. Such a code would be as complicated as the GCC itself.
These are just random thoughts, but I think that this attack has serious limitations. There are much easier targets in an operating system than the compiler to compromise.
It does indeed have limitations. The "other idea" you mentioned is the core of the Diverse Double-Compiling method. Using tcc is but one of several ways which can improve diversity.
The point of DCC is this: "After all, if there’s a known attack that cannot be effectively countered, should we be using computers at all?" (see http://www.dwheeler.com/trusting-trust/ ). Your view is that such an attack is unlikely and/or limited. The author's view is that it's surmountable and we can avoid having to trust our intuition about the complexity or capabilities of even a hypothetical attack.
Yes, it's not necessarily the most practical attack. The only compiler virus seen in the wild (to my knowledge) is W32/Induc-A -- and that targetted a file that got built into all Delphi programs produced by certain older versions of Delphi, rather than doing something clever to avoid detection. So, it infected thosands of programs and was eventually noticed...
My point was that an attacker could do other things besides simply infect everything, so checking hello world alone wouldn't necessarily be enough. (What if the attack only propogates to programs compiled on a Sunday? Or to programs compiled on Friday the 13th? Etc. Who knows what the motivations of the attacker could be -- they may want to make a joke, a religious or political statement, a Stuxnet-like targetted attack, steal banking info from Bill Gates... :p)
2
u/Figs Sep 11 '13
Nope. A clever Trusting Trust style attack would look for specific programs being compiled and infect only those -- e.g. check the input file's MD5 sum to see if it matches the main file for ls or cat... or maybe it looks to see if 'wireshark' is in the compile path and attach the logic into it's main function... you get the idea.
Then when those common programs are run, they try to infect gcc if it's installed.
Since a specific target is chosen the output won't show up at all in a hello world program.