Is Open Source safe? [Linux Weekly News]

Forwarded message:

> X-within-URL: http://lwn.net/1998/1119/Trojan.html

>                                THE TROJAN HORSE
>                                        
>                                        
>     Bruce Perens <bruce@hams.com>
>     
>    
>    There's a problem that could very badly effect the public perception
>    of Linux and Open Source. I want people to think about this, and
>    hopefully "head it off at the pass" before it happens.
>    
>    Perhaps it's already on your system today: a trojan-horse program. It
>    might be a game, or more likely a system utility. It's author uploaded
>    it to an FTP archive, where it was then picked up by your favorite
>    Linux distribution, who wrote it onto the CD-ROM that you bought. It
>    works just fine, but hidden away in the program is a special feature:
>    a secret back-door past your system's security.
>    
>    Perhaps the author of this attack is tired of hearing about what great
>    hackers we are, and wants to take us down a notch. He's patient - he
>    will wait until his program is distributed to tens of thousands of
>    Linux systems before he says a word. But say is what he'll do - he's
>    not really interested in breaking into your system. What he wants is
>    the publicity, bad publicity for us, and lots of it. We've left the
>    gates open for this trojan horse. Let's talk about how to close them,
>    and hope we have enough time to solve this problem before our
>    reputation is hurt.

[mnoga tekct oodalyaty]


    ____________________________________________________________________
 
             Technology cannot make us other than what we are.

                                           James P. Hogan

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

I don't quite understand the logic behind this. The fact that the
program's source is available is itself a proof that there are no
backdoors. Anyone can read the source code and make sure it's OK.

However, this argument does hold against non-OSS. It can even be used to
promote Linux (and other free open-source operating systems), since
someone could distribute some win32 trojans on download.com, tucows.com
and others.

Regards,
--
Vlad Stesin 
vstesin@cs.mcgill.ca

On Sun, 22 Nov 1998, Jim Choate wrote:

> 
> Forwarded message:
> 
> > X-within-URL: http://lwn.net/1998/1119/Trojan.html
> 
> >                                THE TROJAN HORSE
> >                                        
> >                                        
> >     Bruce Perens <bruce@hams.com>
> >     
> >    
> >    There's a problem that could very badly effect the public perception
> >    of Linux and Open Source. I want people to think about this, and
> >    hopefully "head it off at the pass" before it happens.
> >    
> >    Perhaps it's already on your system today: a trojan-horse program. It
> >    might be a game, or more likely a system utility. It's author uploaded
> >    it to an FTP archive, where it was then picked up by your favorite
> >    Linux distribution, who wrote it onto the CD-ROM that you bought. It
> >    works just fine, but hidden away in the program is a special feature:
> >    a secret back-door past your system's security.
> >    
> >    Perhaps the author of this attack is tired of hearing about what great
> >    hackers we are, and wants to take us down a notch. He's patient - he
> >    will wait until his program is distributed to tens of thousands of
> >    Linux systems before he says a word. But say is what he'll do - he's
> >    not really interested in breaking into your system. What he wants is
> >    the publicity, bad publicity for us, and lots of it. We've left the
> >    gates open for this trojan horse. Let's talk about how to close them,
> >    and hope we have enough time to solve this problem before our
> >    reputation is hurt.
> 
> [mnoga tekct oodalyaty]
> 
> 
>     ____________________________________________________________________
>  
>              Technology cannot make us other than what we are.
> 
>                                            James P. Hogan
> 
>        The Armadillo Group       ,::////;::-.          James Choate
>        Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
>        www.ssz.com            .',  ||||    `/( e\      512-451-7087
>                            -====~~mm-'`-```-mm --'-
>     --------------------------------------------------------------------
> 
>

Vlad Stesin wrote:
> I don't quite understand the logic behind this. The fact that the
> program's source is available is itself a proof that there are no
> backdoors. Anyone can read the source code and make sure it's OK.

Anyone can, but does anyone? Also be aware that most people don't
compile from source--it would be easy to doctor the source, compile a
binary, and ship the trojan binary alongside the unmodified source.
 
> However, this argument does hold against non-OSS. 

Yes it does, but not quite in the same way. For example, I believe that
in days of yore some attackers managed to insert a back door into some
DEC OS by breaking into the coding environment (I don't recall the
details, does anyone else?). So in other words, not only _could_ this
happen with non-OSS, it _has_ happened, and no doubt it happens
reasonably often.

In short, this is a real problem, but it seems to be that the likes of
Linux ought to be able to leverage its decentralised and parallel
development model to address it in a more comprehensive manner than any
closed centralised model could ever hope to achieve. "Many eyes"
_should_ make for defence in depth against this--but it does look like
some process is needed, and the Linux folk will need some kind of
argument to convince people that it works. 

Perhaps a start would be for individuals to essentially certify software
that they had personally checked, offering repositories with detached
signatures for specific versions of software compiled in a certain way.
Software that hadn't yet been certified or which didn't match sufficient
independent signatures could then be referred to a human for checking,
and if it was OK then that version of the software could also be signed.
This would also serve as a highly visible "yes, we have checked this for
back doors" statement..."and here are 1,000s of signatures to prove it"
:)

Cheers,
Frank O'Dwyer.

>Frank O'Dwyer <fod@brd.ie> opines:
>>Yes it does, but not quite in the same way. For example, I believe that
>>in days of yore some attackers managed to insert a back door into some
>>DEC OS by breaking into the coding environment (I don't recall the
>>details, does anyone else?).

At 09:43 AM 11/23/98 -0800, Martin Minow wrote:
><http://www.acm.org/classics/sep95/> describes how the inventors
>of Unix inserted a backdoor into the Unix login program. It's well
>worth reading. However, there is no indication that this trojan
>horse ever shipped to customers.

Well, try logging in as "ken", and I think the password was "nih" :-)
(At least when I was starting my Unix career, it was still common
to have logins "ken" and "dmr" around as a courtesy, though eventually
computer security changed that practice.)

Also, mixing up DEC and Unix has long tradition; back in 1979,
there was an article in one of the Oakland or SF papers about
"Hackers at Berkeley" cracking security on "the Unix, a computer 
made by DEC", which was really about abusing answerback on VT100s.


				Thanks! 
					Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

On Mon, 23 Nov 1998, Frank O'Dwyer wrote:

> 
> Vlad Stesin wrote:
> > I don't quite understand the logic behind this. The fact that the
> > program's source is available is itself a proof that there are no
> > backdoors. Anyone can read the source code and make sure it's OK.
> 
> Anyone can, but does anyone? Also be aware that most people don't
> compile from source--it would be easy to doctor the source, compile a
> binary, and ship the trojan binary alongside the unmodified source.
>  

True enough.  Groups that produce software that play a critical role in 
security almost always sign the binaries.  

> Yes it does, but not quite in the same way. For example, I believe that
> in days of yore some attackers managed to insert a back door into some
> DEC OS by breaking into the coding environment (I don't recall the
> details, does anyone else?).

Break into the coding environment?  Does that mean they broke into
the VMS development shop?

> In short, this is a real problem, but it seems to be that the likes of
> Linux ought to be able to leverage its decentralised and parallel
> development model to address it in a more comprehensive manner than any
> closed centralised model could ever hope to achieve. "Many eyes"
> _should_ make for defence in depth against this--but it does look like
> some process is needed, and the Linux folk will need some kind of
> argument to convince people that it works. 

Already proven.  The emergent behavior of the Linux development model
does not need centralized process to coordinate it.  People who had
access to the source and were aware of the teardrop attack hacked a
patch to it almost immediately.  The patch was widely available the
next day.  How long did it take for microsoft?

jim

Jim Burnes - Denver wrote:
> Already proven.  The emergent behavior of the Linux development model
> does not need centralized process to coordinate it.  People who had
> access to the source and were aware of the teardrop attack hacked a
> patch to it almost immediately.  The patch was widely available the
> next day.  How long did it take for microsoft?

Agreed, but that's a different issue. Here we're talking about
deliberately inserted back doors. Those can get extremely nasty, and may
be unpatchable. Examples include "data kidnap" (encrypting the target's
information in situ and demanding a ransom for the decryption key), and
"data cancer" (slow corruption of the target's information, ensuring
that the backups are also corrupted). Quickly patching the software that
delivers those attacks isn't anough--you need a defence against it being
introduced and activated in the first place. I haven't heard of any real
examples of such attacks, but that's not especially comforting.

Cheers,
Frank O'Dwyer.

I reckon an easy and plausibly deniable way to insert a backdoor is to
purposefully make the software vulnerable to buffer overflow (the good
old unchecked gets(3) type of bug, of which a new one is found weekly
in sendmail).

Then send the target an encrypted spam or whatever which their program
decrypts, and in the process exploits the buffer overflow and allows
you to execute arbitrary code, which you use to patch the binary, or
install a keyboard sniffer or whatever.  Works better with DOS/windows
-- with no protection -- you could format the disk if you wanted.
unix a bit more tricky, but doable nonetheless -- enough OS security
vulnerabilities to send along a program to obtain root, and then patch
the binary.

Nice and deniable too, if someone finds the vulnerability, you go
`whoops!' and remove it.

I spent a few hours examining pgp263i for buffer overflow
opportunities, but found no exploitable opportunities in that quick
search.

Areas where things almost work from offerflow is fixed size buffer for
storage of -----BEGIN BLAH----- lines, and I did wonder about the
decompression code also -- quite hairy, and undefined behaviour may
just be obtainable with the right carefully corrupted message sent in.

This exercise ought to be done on pgp5.x and 6.x.  I have spent some
time looking at the code in general -- yuck -- OO overdone, very hard
to read due to the many many levels of inheritence and so on, you
really need to run it under a debugger to even figure out what would
happen half the time.  I think I preferred pgp263 for readability and
clarity.  Werner Koch's GNUPG gets an A+ for coding clarity also --
way better than either pgp2.x and pgp5.x.

Adam

Frank O'Dwyer <fod@brd.ie> opines:
>
>Yes it does, but not quite in the same way. For example, I believe that
>in days of yore some attackers managed to insert a back door into some
>DEC OS by breaking into the coding environment (I don't recall the
>details, does anyone else?).

<http://www.acm.org/classics/sep95/> describes how the inventors
of Unix inserted a backdoor into the Unix login program. It's well
worth reading. However, there is no indication that this trojan
horse ever shipped to customers.

>So in other words, not only _could_ this
>happen with non-OSS, it _has_ happened, and no doubt it happens
>reasonably often.

I doubt it.

Martin Minow
minow@pobox.com

Martin Minow wrote:
> Frank O'Dwyer <fod@brd.ie> opines:
> >
> >Yes it does, but not quite in the same way. For example, I believe that
> >in days of yore some attackers managed to insert a back door into some
> >DEC OS by breaking into the coding environment (I don't recall the
> >details, does anyone else?).
> 
> <http://www.acm.org/classics/sep95/> describes how the inventors
> of Unix inserted a backdoor into the Unix login program. It's well
> worth reading. However, there is no indication that this trojan
> horse ever shipped to customers.

No, that is a different incident. These were external attackers who
managed to patch the source, and as far as I know it did ship. Could be
an urban myth I guess, but it's clearly a plausible attack.

> >So in other words, not only _could_ this
> >happen with non-OSS, it _has_ happened, and no doubt it happens
> >reasonably often.
> 
> I doubt it.

OK, "reasonably often" is overstating it, perhaps :) 

Cheers,
Frank O'Dwyer.

Vlad Stesin <rmiles@Generation.NET> writes:

>I don't quite understand the logic behind this. The fact that the
>program's source is available is itself a proof that there are no
>backdoors. Anyone can read the source code and make sure it's OK.
>

You're missing the point that Thompson and Ritchie made in
"Reflections on Trusting Trust." To summarize:
1. They added a Trojan Horse function to the login sources.
2. They added code to the C compiler that recognized the
   login source code and inserted the Trojan Horse function,
   then they erased it from the login sources.
3. They added code to the C compiler that recognized the
   C compiler sources and added the code noted in step 2 above.
4. They then erased the source from the C compiler.

Now,
1. If you recompile login using a distributed C compiler, the
   Trojan Horse will be added to the executable, but will not
   be visible in the source.
2. If you recompile the C compiler using an existing C compiler,
   it will add the Trojan Horse insertion function, but this,
   too, will not be visible in the C sources.

I might have missed a step or two here, but you probably get
the picture. The only way to detect the Trojan Horse is to
read the executables. In the actual case, if I remember
correctly, Ken and Dennis didn't try to conceal all their
tracks, so the Trojan Horse was visible in the global symbol
(nm) listing.

>From personal experience, I am aware of at least one manufacturer
of safety-critical computer-controlled hardware who read the
assembly language output by the compiler to validate the actual
machine instructions that were generated.

Martin Minow
minow@pobox.com