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.
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?).
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
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
participants (7)
-
Adam Back -
Bill Stewart -
Frank O'Dwyer -
Jim Burnes - Denver -
Jim Choate -
Martin Minow -
Vlad Stesin