[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Solutions: Trojaned Compilers = Backdoored Binaries



The following is a transcript of a thread I started on the gentoo
linux user forums. I figured this list might care to read the thread.
You can view the thread at
http://forums.gentoo.org/viewtopic.php?t=53194&highlight=gcc phpbb.
I'll attempt to provide a transcript.

Ken Thompson wrote an article { http://www.acm.org/classics/sep95/ }
in the early 80's in which he discussed how to create a C-compiler
that backdoors every binary that it creates. Brian Kernighan admits
that he and Dennis Ritchie actually implemented such a bug in the
early days when they were still developing the UNIX system at Bell
Labs. The trojaned-binaries and compiler were virtually undetectable.
Thompson explains very well how the whole process works in his lecture
{ http://www.acm.org/classics/sep95/ }, and I suggest everyone to read
this piece.



Quote:

At his acceptance of the ACM award ceremony, Kerninhan gave a funny
and frightening talk on trust in systems development. He alleged that
he had placed a trojan horse in the original C compiler for UNIX, so
that whenever it compiled the password program it gave him a back
door. Furthermore, the trojan was so sophisticated that whenever it
compiled the C compiler, it inserted itself in the new executable.
Even if you are running Linux and have read every single line of
source, you must have bootstraped from somewhere. How do you know that
it hasn't inserted Trojan horses all through your system?


I see such a bugged GCC in Gentoo to be quite possible and extremely
dangerous. I'm not saying that their is more risk involved with Gentoo
alone as a Linux distro. However I do think given the source-based
nature of Gentoo that a solution to this admitably unlikely security
problem could be easy designed and implemented. It is foolish for us
to think that just because we are running an operating system that we
compile from source we are somehow automatically secure.

If such a trojan were to infect Gentoo than effectively our entire OS
will have been compromised, because every app thereafter will be
backdoored, in many possible ways that have even yet to be concieved.
It would only be known by the perpetrateurs (those who setup such an
infection in Gentoo) that pretty much every Gentoo user in existence
is using backdoored software, but if that institution/organization
were large enough than it would be a serious enough problem. Just read
this discussion {
http://groups.google.com/groups?hl=en&lr=lang_en&ie=UTF-8&safe=off&threadm=3D0E94A2.90C90826%40pobox.com&rnum=13&prev=/groups%3Fq%3Dkernighan%2Bcompiler%2Btrojan%26num%3D30%26hl%3Den%26lr%3Dlang_en%26ie%3DUTF-8%26safe%3Doff%26sa%3DN%26tab%3Dwg
} on alt.security.pgp discussing the possible problems with a
backdoored gnupg.

I don't think that we can just assume that this is all overhyped and
paranoia. I don't think we can just "trust" anything enough to not at
least discuss a way to overcome this possible security problem.
Admitably any type of large-scale organization such as a government
agency that was interested in backdooring an operating system would
probably find it easier to coerce our favorite Redmond company in
doing { http://www.heise.de/tp/english/inhalt/te/2898/1.html } such a
thing { http://www.heise.de/tp/english/inhalt/te/5263/1.html }. I
would love to see Gentoo take an approach to become something that we
can increasingly trust {
http://www.gnu.org/philosophy/can-you-trust.html }. All it would take
is for the GCC on the .iso files which every Gentoo user bootstaps
with to be compromised.

Seeing as Portage is one of the most powerful and adaptable package
installers to date, I think we may just be able to overcome the
trojaned compiler problem. I am definitly not going to be able to
handle the technical aspects of this situation, as I am not a
programmer or developer (just a linux junky). The only solution I
could imagine would be creating a script that would build GCC from
ASM, or somehow assemble a trusted environment of distribution methods
where we know that the GCC we use to bootstrap from is not infected
(although it is hard to tell). I hope I haveproven to the developers
that they should take this whole issue into consideration for future
versions of portage and Gentoo. I think to overcome this obstacle
would be a interesting pursuit, and would definitly be an amazing
acheivement as far as OS security goes. Gentoo would be the only OS
with such a mechanism to prevent backdoors that I know of, and I know
of many others { http://freeos.com/compare/ }.



I just thought I would link {
http://www.google.com/search?num=30&hl=en&lr=lang_en&ie=ISO-8859-1&safe=off&q=Reflections+on+trusting+Trust&btnG=Google+Search
}to a relevant google search for those intrested in further pursuing
information on this subject.

__________

Here is one reply on the thread which is pretty interesting:

It is interesting. 

Although my computer is a toy so it doesn't worry me that much, sure a
government could pinch my rtcw key perhaps, but then again, they seem
happy enough to kill people so it's not as if pgp will really help in
that case.

It does make sense for more casual petty crime though. 

As you say, it's not gentoo specific - the c compiler / kernel /
firmware used by the machine / maintainer at your fave binary distro
has exactly the same issue.

firmware pretty much means that if you believe in evil empires as your
Redmond comment suggests, why do you trust the mobo manuf? Or the hard
disk or bios manuf? - Imagine that your new secure C code download
compiles passwd then your hard disk controller adds a
backdoor....That's pretty much where the new secure platforms is
supposed to create a trustworthy computer system from hardware upwards
- and the big debate about who exactly trusts it - and who it's really
securing begins - the DRM issue et al.

Although it's generally not the case that the actions of a trojan
remain undetected, nor that most users get infected...(although I
guess if a truely undetected trojan exists - you wouldn't know about
it by definition but for it to be of any benefit to the installer, it
would likely have to reveal itself by its actions - especially if it
did the kind of actions your average hyperbole filled media doom story
depicts)

1 user might not notice, 100 or 1000 might not, get enough and someone
will - think about bug reports, how many "everyone" gets contrasted
with how many people use software that is evidently full of bugs as a
glance at their development process will show (the linux kernel for
instance), but many rarely, if ever, hit one.

As for Bill Gates, I can't see the richest bloke in the world gets
coerced too often, an MS employee perhaps - depends what checks and
balances their development system has - do you know every Linux
developer personally - Is one in debt? Has one committed a crime that
a government could use as a lever, would one do it anyway for a big
enough pile of money? There's no logic in the idea that a loosly knit
team of developers are in any sense less likely to be coerced - except
perhaps that a fair number have no particular interest in the US
governments aims and objectives, maybe even the converse - and of
course, they may have their own persuasive government workers where
they live.

The key thing is what the checks and balances are in the process that
would prevent or detect one individual from that kind of action.

________

Another interesting reply:

A very interesting read, i followed all the links and was quite
surprised with what i read....

... "Ignorance is bliss" ..... 

That being said... here's my nickels worth.... i am not a
developer/programmer so i may not know what i'm talking about....

Isn't that bordering on paranoia? I mean, at what point does one stop
being security proactive and simply paranoid. Sitting at my desk, i
have to trust that my monitor isn't sending radio messages containing
my keystrokes... i have to trust that my bottle of water has no poison
in it....

As was explained in the Microsoft secret NSA key article,
compartmental development allows code to sneak in quite easily without
a peer's review. That same development tactic is also one used by
terrorists and their cells. Intelligence agencies and their
departments. The idea is that no one person (or a very small amount)
knows what the really large picture is and what's truly going on. In
this aspect, we as a community do not suffer much in my opinion. The
OSS development is the most open method that promotes peer review. For
that reason, i believe this problem is a minor one in our community.

If you can't trust GCC, and can't trust the developers.... what are we
left with? Turning to a hardware solution would be a step back if
anything... It would make locating any potential problems
exponentially harder. Coding the compiler in asm would simply allow
the Assembly compiler to be comprimised.... using binaries only would
simply result in the millions of spyware that has infected our windows
friends...

Although some would say this is all paranoia, myself included... i can
understand why others might worry. I can only speculate what would be
so precious that they would throw away trust in another human without
reason.... but i can understand why it would happen. If anything, the
first article linked in the original post shows that the impossible
can become a very serious reality.

IMO you can't plan for this problem, attempting to find a solution is
an exercise in futility given our current technology.... I liken it to
an earthquake. It's going to cost me money, destroy every material
item i have, and yet... there's not a damn thing i can do about it....
 __________

Do you guys think I am nuts to even care about this? Personally I see
it as a very real security issue. I was just wondering what the
devs/users of arguably the most secure OS think about this issue. I
apologize on the length of the email but I know some people prefer not
to follow links so I figured I would post a comparatively brief
transcript. Do you guys think this is a real problem to be concerned
with? Does a solution already exist?