Re: old intentional gcc bug?
The differences you are seeing now are likely caused by differences in autoconf configuration for the case of GCC compiler versus non-GCC compiler. One of the results of toplevel bootstrap is to eliminate these differences in autoconf configuration. Paolo
Re: old intentional gcc bug?
On Jun 24, 2007, at 16:20, Eric Botcazou wrote: Indeed. It would be interesting to confirm whether or not a copy of gcc bootstrapped with a non-gcc compiler matched byte-for-byte with a copy of gcc bootstrapped from gcc. I just made the experiment on an old SPARC/Solaris 2.5.1 machine and they differ (cc is Sun C 5.0 and gcc is GCC 3.4.3): Still, if you use these two bootstrapped, slightly different compilers as base for a fresh bootstrap in a new build directory, you'll likely get identical results and that would still prove that there is no self-propagating back door in GCC on that configuration. The differences you are seeing now are likely caused by differences in autoconf configuration for the case of GCC compiler versus non-GCC compiler. While these shouldn't propagate to the final binary, it's easy for some things to slip through. There's no real incentive to work hard to prevent that from happening. -Geert
Re: old intentional gcc bug?
Still, if you use these two bootstrapped, slightly different compilers as base for a fresh bootstrap in a new build directory, you'll likely get identical results and that would still prove that there is no self-propagating back door in GCC on that configuration. Probably. But, as Mike told me privately, STABS are sensitive to the build directory, so I tried again and got identical executables byte-for-byte: sunshine% ls -l gcc.cc/gcc/cc1 -rwxrwxr-x 1 eric eric 46745912 Jun 25 03:30 gcc.cc/gcc/cc1 sunshine% ls -l gcc.gcc/gcc/cc1 -rwxrwxr-x 1 eric eric 46745912 Jun 25 07:00 gcc.gcc/gcc/cc1 sunshine% cmp gcc.cc/gcc/cc1 gcc.gcc/gcc/cc1 sunshine% -- Eric Botcazou
Re: old intentional gcc bug?
On Jun 25, 2007, at 10:59 AM, Eric Botcazou wrote: Probably. But, as Mike told me privately, STABS are sensitive to the build directory, so I tried again and got identical executables byte-for- byte: Cool. Glad you could verify them on a byte for byte basis. This helps keep your compiler vendors honest by ensuring that their distributed binary (both for solaris compiler and the original gcc one used to build gcc) doesn't _seem_ to contain a propagating bad code virus. Now, please tell me you didn't also compile cmp yourself... :-) Or wait, do we trust cmp from the vendor, oh no, my head explodes. :-)
Re: old intentional gcc bug?
On Jun 23, 2007, at 2:38 PM, Robert Dewar wrote: On the contrary, since gcc can always be built using third party C compilers, it would be much easier to smoke out and eliminate any such behavior (indeed this example shows the merit of maintaining the property that gcc can be compiled by non-gcc compilers), although we have not been able to maintain that property for the Ada front end. Plus, you can audit old binaries to find evidence this had been done by recompiling gcc with 5 different C compiles on 5 systems and then using those to compile up the claimed sources for the binary and see if it matches the binary in question. If you're a system distributor, you limit who can inject binaries into the build system, log and audit it.
Re: old intentional gcc bug?
Indeed. It would be interesting to confirm whether or not a copy of gcc bootstrapped with a non-gcc compiler matched byte-for-byte with a copy of gcc bootstrapped from gcc. I just made the experiment on an old SPARC/Solaris 2.5.1 machine and they differ (cc is Sun C 5.0 and gcc is GCC 3.4.3): Using built-in specs. Target: sparc-sun-solaris2.5.1 Configured with: /home/eric/svn/gcc/configure --prefix=/opt/build/eric/local/gcc --with-gmp=/opt/build/eric/local --with-mpfr=/opt/build/eric/local --with-local-prefix=/opt/build/eric/local --enable-languages=c --enable-checking=assert,misc,runtime Thread model: posix95 gcc version 4.3.0 20070623 (experimental) sunshine% ls -l gcc.cc/gcc/cc1 -rwxrwxr-x 1 eric eric 47123792 Jun 24 07:38 gcc.cc/gcc/cc1 sunshine% ls -l gcc.gcc/gcc/cc1 -rwxrwxr-x 1 eric eric 47126188 Jun 24 13:40 gcc.gcc/gcc/cc1 Most of the differences seem to come from the .stab section, not sure why. Independently of this, I'm pretty sure that our configure machinery is sensitive to the bootstrap compiler. -- Eric Botcazou
Re: old intentional gcc bug?
On Sat, Jun 23, 2007 at 08:35:19AM -0700, krith htirk wrote: Hi, I've been told that a developer of gcc, in the early stages, put a security hole that allowed him complete access to any computer running unix, as gcc was included in unix, and that it stayed that way until he decided to tell everyone and patch it. I don't believe him, but I couldn't find any information about that in the internet deniying it. That's why I came here to confirm that it never happened. Sorry for my bad English and thank you. Regards. A very similar thing has actually happened, but not with gcc (not that I know of anyway.) Ken Thompson (one of the original creators of Unix) *did* put such a hack into their C compiler which would automatically add backdoor code when it compiled the 'login' program. This was many years ago and AFAIK the hacked Unix version was never released into the wild. You can read more about this hack at http://en.wikipedia.org/wiki/Thompson_hack or http://www.acm.org/classics/sep95/ -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED]
Re: old intentional gcc bug?
Erik Trulsson wrote: Ken Thompson (one of the original creators of Unix) *did* put such a hack into their C compiler which would automatically add backdoor code when it compiled the 'login' program. This was many years ago and AFAIK the hacked Unix version was never released into the wild. Are you sure your information is accurate. Neither of the references that you cite back you up on this. Yes, of course we all know of Ken's proposed design for this (from his ACM talk), but I never read anywhere before that this was actually carried out in the wild or otherwise.
Re: old intentional gcc bug?
On Sat, Jun 23, 2007 at 04:36:02PM -0400, Robert Dewar wrote: Erik Trulsson wrote: Ken Thompson (one of the original creators of Unix) *did* put such a hack into their C compiler which would automatically add backdoor code when it compiled the 'login' program. This was many years ago and AFAIK the hacked Unix version was never released into the wild. Are you sure your information is accurate. Neither of the references that you cite back you up on this. Yes, of course we all know of Ken's proposed design for this (from his ACM talk), but I never read anywhere before that this was actually carried out in the wild or otherwise. The Wikipedia page I referenced (http://en.wikipedia.org/wiki/Thompson_hack) says that: What's worse, in Thompson's proof of concept implementation, the subverted compiler also subverted the analysis program (the disassembler), so that anyone who examined the binaries in the usual way would not actually see the real code that was running, but something else instead. This version was never released into the wild. It was released to a sibling Bell Labs organization as a test case; they never found the attack The Jargon File (http://www.catb.org/jargon/html/B/back-door.html) says: The Turing lecture that reported this truly moby hack was later published as Reflections on Trusting Trust, Communications of the ACM 27, 8 (August 1984), pp. 761--763 (text available at http://www.acm.org/classics/). Ken Thompson has since confirmed that this hack was implemented and that the Trojan Horse code did appear in the login binary of a Unix Support group machine. Ken says the crocked compiler was never distributed. Your editor has heard two separate reports that suggest that the crocked login did make it out of Bell Labs, notably to BBN, and that it enabled at least one late-night login across the network by someone using the login name kt. And reading Ken's ACM paper (http://www.acm.org/classics/sep95/) certainly gives me the impression that he is talking about a real program, not just a purely hypothetical case: [...] I would like to present to you the cutest program I ever wrote. I will do this in three stages and try to bring it together at the end. [...] The actual bug I planted in the compiler would match code in the UNIX login command. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED]
Re: old intentional gcc bug?
Erik Trulsson wrote: And reading Ken's ACM paper (http://www.acm.org/classics/sep95/) certainly gives me the impression that he is talking about a real program, not just a purely hypothetical case: [...] I would like to present to you the cutest program I ever wrote. I will do this in three stages and try to bring it together at the end. [...] The actual bug I planted in the compiler would match code in the UNIX login command. OK, interesting, thanks for info, I had always thought that this was purely conceptual. Of course there is nothing special about open source/free software that makes such attacks more possible. On the contrary, since gcc can always be built using third party C compilers, it would be much easier to smoke out and eliminate any such behavior (indeed this example shows the merit of maintaining the property that gcc can be compiled by non-gcc compilers), although we have not been able to maintain that property for the Ada front end. Of course with a proprietary program, there is no need for such subterfuge, you just put in whatever nefarious stuff you like in the front end (it took a while for people to find the flight simulator in Microsoft Excel).
Re: old intentional gcc bug?
Robert Dewar wrote: OK, interesting, thanks for info, I had always thought that this was purely conceptual. One thing (which Erik didn't mention) that I noticed in the articles is that Ken said that in his implementation he also hacked the disassembler to cover up the evidence. Of course there is nothing special about open source/free software that makes such attacks more possible. On the contrary, since gcc can always be built using third party C compilers, it would be much easier to smoke out and eliminate any such behavior (indeed this example shows the merit of maintaining the property that gcc can be compiled by non-gcc compilers), although we have not been able to maintain that property for the Ada front end. Indeed. It would be interesting to confirm whether or not a copy of gcc bootstrapped with a non-gcc compiler matched byte-for-byte with a copy of gcc bootstrapped from gcc. Not so much to look for intentional things like this, but to see whether the bootstrapping actually does achieve its goal of obtaining a result that's independent of the bootstrapping compiler. Has anyone actually tried it? - Brooks
RE: old intentional gcc bug?
On 23 June 2007 22:53, Brooks Moses wrote: Indeed. It would be interesting to confirm whether or not a copy of gcc bootstrapped with a non-gcc compiler matched byte-for-byte with a copy of gcc bootstrapped from gcc. Not so much to look for intentional things like this, but to see whether the bootstrapping actually does achieve its goal of obtaining a result that's independent of the bootstrapping compiler. Has anyone actually tried it? That's kinda the whole point of bootstrapping :) any variation is in the stage1 compiler only, modulo such bad bugs in the native compiler that the stage1 gcc miscompiles stage2 gcc. cheers, DaveK -- Can't think of a witty .sigline today
Re: old intentional gcc bug?
Brooks Moses [EMAIL PROTECTED] writes: Indeed. It would be interesting to confirm whether or not a copy of gcc bootstrapped with a non-gcc compiler matched byte-for-byte with a copy of gcc bootstrapped from gcc. Not so much to look for intentional things like this, but to see whether the bootstrapping actually does achieve its goal of obtaining a result that's independent of the bootstrapping compiler. Has anyone actually tried it? At Cygnus, in the early and mid- 90s, we did this routinely, starting with the native compilers shipped with various Unix variants. As Unix variants generally no longer come with a free (as in beer) compiler other than gcc, this is harder to test today. Still, not too hard: you would just start with some other free compiler. Ian
Re: old intentional gcc bug?
Dave Korn wrote: On 23 June 2007 22:53, Brooks Moses wrote: Indeed. It would be interesting to confirm whether or not a copy of gcc bootstrapped with a non-gcc compiler matched byte-for-byte with a copy of gcc bootstrapped from gcc. Not so much to look for intentional things like this, but to see whether the bootstrapping actually does achieve its goal of obtaining a result that's independent of the bootstrapping compiler. Has anyone actually tried it? That's kinda the whole point of bootstrapping :) any variation is in the stage1 compiler only, modulo such bad bugs in the native compiler that the stage1 gcc miscompiles stage2 gcc. Right, exactly. I'm an engineer; you give me a theory like that, and I become curious how much it's been tested in practice. :) - Brooks
