Green Hills Software on free software in the military [LWN.net]

Green Hills Software on free software in the military

Posted Apr 8, 2004 22:20 UTC (Thu) by allesfresser (subscriber, #216) [Link]

By the way, the Ken Thompson episode they refer to is documented by Thompson himself here. It involved patching the compiler so it would recognize that it was recompiling itself and reinserting the trojan horse code that it was meant to carry. Of course, that was a different era where it was easier to get away with things like that (no MD5 sums for the tarballs, etc.)

They are truly trying to pull a rabbit out of a hat on this one...the chances of being able to pull something like that these days with the vast array of people using different versions of lots of different packages would be rather small.

Green Hills Software on free software in the military

Posted Apr 8, 2004 23:30 UTC (Thu) by dmenest (guest, #4017) [Link]

Also, the problem of not being able to trust the compiler that compiled the compiler that compiled the compiler . . . is not restricted to Free/Open Source Software. Proprietary software is just as vulnerable. Even if Green Hills writes their own compiler, which compiler did they use to compile it?

Cross compiling compiler

Posted Apr 9, 2004 5:29 UTC (Fri) by libra (guest, #2515) [Link]

Althought I never tried it, I think that by using different compiler on different platforms and cross-compiling for one shall give at second iteration identical compiler codes no matter the original compiling platform.

If this can be shown it will prove that no secret code is in the compiler because it would mean otherwise that all compilers on all platforms are corrupt, and that is unpossible.

Maybe someone out here as a clue on that topic, or can explain why that idea could be wrong.

Cross compiling compiler

Posted Apr 9, 2004 6:29 UTC (Fri) by pynm0001 (subscriber, #18379) [Link]

I'm not sure exactly what you mean, so I'm going to give an example, and you can tell me whether it's right or wrong.

You're saying that if you have (say) Solaris CC on Pentium compiling for Sparc, and gcc on PowerPC compiling for Sparc, that the resulting object code for Sparc should be identical on both machines?

The answer would be no, unfortunately, unless a fluke occurred. If both compilers are good, they will produce equivalent code, but the code will almost certainly not be byte-for-byte equal.

However, even if the compilers produce byte-for-byte identical code, that doesn't mean that secret code in a compiler is impossible, because I could go and write a compiler later that adds secret code. The problem with your logic is that producing identical output for two compilers doesn't imply that all compilers on all platforms are either all corrupt or all clean.

Cross compiling compiler

Posted Apr 9, 2004 7:28 UTC (Fri) by baldrick (subscriber, #4123) [Link]

Probably what he means is that you bootstrap gcc using a non-gcc
compiler and also using gcc itself. If the final gcc you get is the same
in both cases then you can be pretty sure there is no Thompson trojan
lurking inside gcc. I understand that this is one of the reasons the gcc
developers work hard to make gcc compilable by a wide range of other
compilers.

Cross compiling compiler

Posted Apr 9, 2004 7:37 UTC (Fri) by pynm0001 (subscriber, #18379) [Link]

Ah, that's a good idea. Although I feel that my other argument about
equivalent code remains. A non-gcc compiler shouldn't produce the same
exact binary that gcc itself would, merely one which works the same.

Cross compiling compiler

Posted Apr 9, 2004 12:13 UTC (Fri) by libra (guest, #2515) [Link]

That's why I added the term iteration in my post. The idea is :

Compile GCC with compiler C_A on platform P_A for platform P
Compile GCC with compiler C_B on platform P_B for platform P
(with C_A != C_B and P_A != P_B but not necessary C_x != GCC or P_x != P)

Then on platform P you have GCC_A and GCC_B, they are certainly note binary equivalent, but functionally shall be. As the code has been audited, and two platforms/compiler were involved, we may assume that one of the two is not tainted. So now we do :

Compile GCC with GCC_A on P
Compile GCC with GCC_B on P

If both GCC_A and GCC_B are really functionally equivalent then the results shall now be binary identical (at that iteration, or maybe at the next one due to some cross compilation problems that may occur). If you can never reach an iteration where both results are stable and identical, then you have a problem, otherwise you nearly have the proof you want (unless all compiler of the world are tainted the same way, highly unlikely).

Note that for better results it shall be done with 3 or 4 different compiler. Also note that if you find a small binary difference at some point you may very well gain the key of the backdoor (in GCC or in C_x) by analyzing that difference, unless it is just a bug you would have to point out for the improvement of GCC.

Sorry not to have been clear the first time. Hope it is OK now.

Cross compiling compiler

Posted Apr 9, 2004 19:54 UTC (Fri) by pynm0001 (subscriber, #18379) [Link]

I see what you're saying now (I was up too late last night :-( ).
Indeed, it sounds like a very good idea, I can't see any flaws in the
logic.

Of course, we can't even apply that test to MSVC, so I guess Open Source
wins another security battle due to the other side's forfeit. :-)

Cross compiling compiler

Posted Apr 11, 2004 21:27 UTC (Sun) by flewellyn (subscriber, #5047) [Link]

This could only happen if the code-generating back-ends for all of the different compilers were identical. Unless the different compilers were derived from a common base, this is unlikely.

I think a better means of ensuring the security of a compiler is simply to examine its source code. Of course, with proprietary compilers (the type that Green Hills is pushing), you can't do that, so you just have to trust them. Which is what Green Hills is saying is the problem with free software...sounds like someone has their brain on backwards.

O'Dowd did not learn Thompson's lesson

Posted Apr 9, 2004 22:18 UTC (Fri) by brouhaha (subscriber, #1698) [Link]

Mr. O'Dowd of Green Hills Software obviously didn't really learn anything when reading Ken Thompson's paper, or he would realize that the trust problem Thompson described is just as severe with commercial closed-source software. Actually, the compiler trojan Thompson described was for commercial, closed source software.

In fact, open-source software may have a slight advantage here, because it's less of a monoculture. Presumably Microsoft always uses their own Visual C++ compiler to build Windows, so if there were a trojan in the compiler that compromised the resulting Windows executables, it would be present in all copies of Windows that Microsoft distributed. But open source software is by its nature built on many different platforms using different compilers, so a compiler trojan would only affect a portion of the deployed copies of the open source software. And it is possible that a trojan introduced by one particular compiler would be found due to the executable it produces being different in some noticable way from the executable produced by a different compiler. For instance, strace might show the trojaned executable making extra system calls.

How does Mr. O'Dowd propose to assure us that his company's operating systems and compilers are more secure than Linux, xBSD, GCC, etc? Is he certain that none of his employess who have written code incorporated into his products have ever installed trojans? If so, how has he gained this certainty? Has he scrutinized every line of source code himself? Including those of the compilers that compiled the compilers, back all the way to the machine-code only origin of the system? Somehow I doubt it.

It is a matter of historical fact that far more trojan and back door exploits have been present in commercial, closed source software than in open source software. Just two days ago Cisco had to issue a security advisory regarding a back door found in their WLSE and HSE products. Would Mr. O'Dowd conclude that foreign agents and terrorists are responsible for that? Would he really have us believe that these shadowy figures can compromise open source software developed in the public eye more easily than they could subvert a commercial closed-source software package for which the source code and development process get no public scrutiny?

One is forced to conclude that Mr. O'Dowd feels his company's business model is threatened, and rather than change that model to reflect changes in the marketplace, he prefers to use "the sky is falling" proclamations in an attempt to scare customers into sticking with his products.