|
|
|
| Authored by: bugstomper on Tuesday, January 22 2013 @ 03:24 PM EST |
It isn't a matter of bootstrapping. Or rather, it is a matter of creating the
compiler using an alternate bootstrap path.
Here is the problem: What if someone put a trojan horse in a compiler like gcc
that would cause it to produce a vulnerability when it is used to compile
certain code, then added something to insert that trojan horse in the binary
output produced when the compiler detects that it is compiling itself, then
removed that trojan horse code from the source code of the compiler, and then
released the resulting binary of the compiler? If they could get people using
that hacked binary of the compiler, it would not matter if people as a
precaution inspected the source code of the compiler and compiled it themselves
to make sure that they knew what was in their compiler. For example, with one
free software compiler project that I work on what I usually do as a test after
updating the sources is I compile the compiler twice, once using the currently
installed version, then again using the result to compile itself. A rough test
for things being broken is whether repeated compiles of itself by itself produce
bit for bit identical results (once I remove timestamps in the output). But if
all of the compiler binaries contain a hack that inserts itself into the binary
only when the compiler compiles itself, I would never know.
The solution is to compile gcc (in this example) with any other compiler that I
can be sure does not have the identical trojan in it. It would compile the
sources of gcc and produce code that does what the sources say, not with the
trojan horse that makes gcc produce malware. Now I have an executable of gcc
that I know does not contain that particular trojan that makes that particular
modification to the output when it is used to compile gcc. I compile gcc with
the binary of gcc that I just made and compare it to the result of compiling gcc
with the binary of gcc that I made using the publicly available gcc. If the
results are not the same then the publicly available gcc binaries are suspect.
To do this all I need is a C compiler that is sufficiently complete that it can
compile gcc. It doesn't have to produce the most optimized code, it just has to
work. I can go to the effort of writing my own compiler, bootstrapping it or
whatever, but I don't have to go to the tremendous effort of producing a
compiler as production quality as gcc. Or I can use someone else's C compiler
knowing that even if it is compromised with a trojan horse it will not be the
same trojan horse as the one in the gcc executables, so it will still work for
this purpose.
The result will be that I have verified that the gcc executable I have really
does correspond to the gcc sources that I have inspected. I can then use gcc, a
production quality free open source compiler, instead of the bare bones compiler
I wrote myself or obtained elsewhere that I used to conduct this exercise.
[ Reply to This | Parent | # ]
|
|
|
|
|
