In my last column, I explained how the
availability of source code can let an attack take an exploit that
merely makes a program dump core and turn it into an attack that can
give away root privileges. But there is another way that source code
can become a tool for an attacker: source code makes it easier for
an attacker to take a legitimate program and turn it into a Trojan
Horse by adding back doors or logic bombs.
Source
code makes things easier for a malicious programmer for the same
reason that it helps legitimate programmers who are adding new
features or fixing bugs. When you have a program's source
code, you don't need to reinvent the wheel. You can simply add the
functionality that you wish. This is true whether the functionality
is for good or for evil.
The threat of Trojan Horses was one
of the primary fears voiced when Netscape decided to release the
source code for Netscape Navigator. Many commentators said that it
would only be a matter of time before rogue versions of Netscape
were careening around the Internet, pretending to be legitimate
copies of Mozilla. Imagine the possibilities. You could create a
special version of Mozilla that automatically recognized credit card
numbers being posted on web forms and copied to undisclosed
third-party countries. Or you could have a version of Mozilla that
allowed encrypted "telnet" access to an attacker who wanted to
browse your mail file.
This is not just idle speculation:
Trojan Horses are widely proliferating on the Internet
today. For example, in March 1999 Patrict Oonk reported to
the Bugtraq mailing list about a free email program called ProMail
that contained a Trojan Horse. The program, which supported multiple
POP3 accounts, virus scanning, filters, and an "advanced scheduler,"
also surreptitiously took the user's account username and password,
encrypted the information, and sent it to an anonymous email
account. Just imagine what this program's author could have done if
the source code at Mozilla.org had been good enough for general use!
Of course,
one advantage of open source software is
that you can always inspect the program to see if it has a Trojan
Horse or back door. But let us be honest: when was the last
time that you personally inspected a program, line by line, to make
sure that it was kosher to run as root? The source code for the
Secure Shell (SSH) version 2.08 is 106,387 lines long; a competent
programmer can hide a fairly devastating Trojan Horse in less than 4
lines of code. Yet I don't know of a single system administrator who
has ever examined the code line-by-line: they just run "configure,"
"make," and "make install." Many don't even edit the SSH config
file!
Yet back doors have been hidden in source code. In
January 1999, an attacker
broke
into the source code repository of Wietse Venema's TCP wrappers
and replaced the code with an altered package that contained a
back
door. Even though the substitution was discovered within a day,
52 sites downloaded the adulterated program.
Compounding the
danger of open source Trojan Horse programs is the fact that most
people in the open source community have stopped downloading source
code entirely; instead, they download precompiled binaries for their
particular operating system and microprocessor. This tendency is
particularly strong among Linux users, thanks to the Red Hat Package
Manager (RPM).
One way that the software developers on the
Internet have tried to deal with the threat of Trojan Horses is to
tell people to download programs only from specific machines. For
example, the SETI@home project recently put a message on its website
saying "some users are distributing unauthorized patches to the
SETI@home client. We cannot verify that these patches function
properly and are virus free. It is very important to the science of
SETI@home that you run only the unmodified SETI@home program."
But what's really needed is for open source
proponents to take the threat of Trojan Horses seriously.
We need to develop better systems for automatically certifying
source code and object code before it is installed. Digital
signatures are a good first step, but signed code is not a silver
bullet. We need to develop tools for analyzing code before and while
it is running. And we also need to redesign our operating systems to
limit the damage that any rogue program can do. Without these
measures, the security of open source systems will be increasing in
jeopardy.
Part IV: Rethinking Security
Through Obscurity 
