by Rik Farrow
People often ask me if they should trust Open Source Software. The questions predate the emergence of Linux and the various BSD operating systems, as popular security software for UNIX systems, such as COPS and Tripwire, began showing up in the early nineties. Organizations accustomed to paying big bucks for any software they planned to use were understandably cautious about free software that didn't come from well know vendors.
And recent events have added a scary twist to Open Source. Several sites, one with security software, had backdoors added to installation scripts, so that anyone who installed the software could have their system compromised. The perpetrators had disguised the backdoors so that they appeared to be part of a normal configuration process.
Open Source Software (OSS) has proven to be as secure, if not more secure, than closed source software from big companies. You can take steps to assure that the software you have downloaded has not been tampered with, simply by verifying the digital signature that many distributers include at their download sites. I'll also explain the recent backdoor, how it worked, as well as how it was discovered.
Programmers add backdoors to software so that they can gain (or maintain) access to systems where that software is installed. With commercial software and systems, backdoors have other names, such as maintenance accounts, and may be well known to the owners of these systems. But not always.
DEC (Digital Equipment Corporation) included several system level accounts with default passwords, so that DEC field engineers would have easy access as the System Manager to VMS operating system installs. DEC's field engineers also were trained in several other ways of gaining system-level access.
Data General Avion systems included a special option as part of the printer server administration command. Use of the special (and undocumented option) provided root access. AT&T field engineers who maintained 3B2 minicomputers would use a bug in the expreserve program to execute commands as the superuser.
Backdoors also have a long history in UNIX software. Ken Thompson explained his magic password, a password that once allowed him to log in as any user on any UNIX system, during his award exceptance speech at the ACM. Thompson, one of the designers of the UNIX operating system, had included a backdoor in the password checking function that gets included in the login program. The backdoor would get installed in new versions of the UNIX system because the compiler itself had trojan code that propagated the backdoor code to new versions of the compiler. Thompson's magic password is the best known (and most complex in distribution) backdoor code. Note that Thompson's backdoor was taken out a long time ago.
Almost as well known, Eric Allman included several backdoors in the earliest version of sendmail. At the time Allman began writing sendmail, only three UNIX systems, all at UCB (University College, Berkeley) ran the software, and Allman already had root access on all of those systems. When sendmail was installed on a fourth system, and Allman was denied access to his new (and buggy) mail software, he added the backdoors.
The term Open Source Software (OSS) would not be coined until 16 years later. Bill Joy, then a student at Berkeley (later a founder of Sun Microsystems), included the backdoored versions of sendmail in a distribution tape copied and sent to the fifty sites, creating the first Berkeley Software Distribution (BSD) in 1982. Now, sendmail, with its various backdoors ran on more systems, and Allman had lost control of both his software and the backdoors included in it. The most egregious backdoor was an "additional" SMTP command, wizard, that provided a root shell to anyone who could provide a configured password. A later performance improvement to sendmail actually wiped out the password, so just connecting to sendmail and typing "wiz" could produce a root prompt.
Commercial UNIX workstation vendors, like Sun and Hewlet-Packard (HP, soon to be Compaq), commented out the code in sendmail for the wizard backdoor. But they missed a second backdoor, debug, that could execute any one line command as root. The Internet Worm, in November 1988, used the debug command to upload and execute a short program that spread the worm. Finally aware of the real meaning of debug, it too was commented out of the sendmail source. The third backdoor. decode, was no more than an alias in a configuration file, and was removed long ago.
The known history of OSS backdoors gets boring after the eighties. The developers of UNIX had gotten religion, and wanted their operating system to become mainstream, and backdoor code is not the route to commercial acceptance.
Not that backdoor code disappeared completely. Perhaps the best known backdoor during this period came from Microsoft. Microsoft Excel included both pictures of the developers and various games, but only if you knew how to invoke the backdoor (also called Easter eggs, see Resources). Note that there are many versions of Excel in use, and not all of them will have hidden games. I first learned of the backdoor in Excel while teaching UNIX security classes at one of the large accounting firms.
FTP servers for OSS were the big target in the early nineties. If someone could break into a site undetected, add modified software to files to be downloaded, then perhaps hundreds or even thousands of unsuspecting people would download and install the software--often running as the root user. Some people used another approach, disguising trojan horses as security software. A recent tool advertised as a vulnerability detector actually would install backdoor when the victim ran the software. This tool actually got posted to a moderated security and vulnerability list.
The security paranoid users of OSS have several choices when they download software. Really paranoid, and tecnically savvy, people read through the entire source code, looking for possible backdoors. A quicker approach is simply to scan the code looking for code that makes network connections, executes commands or opens files, as these are the things most commonly done in backdoor code. If everyplace where these things are done checks out, and everyplace where these functions get called also checks out, then the code is probably okay.
But few people can actually do this for large OSS packages. BIND,
(Berkeley Internet Name Daemon)
the OSS DNS software, has 170,000 lines of source code. And BIND
has been plagued by bugs in recent years, leading to many patches.
In these cases, the security conscious programmers check only
the differences between past versions and the newest release,
which might only be a few lines of code changed or added.
Most people choose to trust the distributers of software, rather than attempt to read and understand the source code. While this approach works most of the time, how does a code consumer know that he or she is working with the authentic version of the source code?
In the Spring of 2002, several software distribution sites were compromised, and subtle modifications made to the software packages that could be downloaded. Two of these sites were for IRC software, and one site, monkey.org, contained software, fragrouter, written by a well-known security expert, Dug Song.
The attackers had in each case modified an installation script commonly used when installing OSS software. The script, named configure, searches the system where the software will be installed, and configures the install scripts (called Makefiles) so that they match the target system. Configure scripts often build short test programs to see if necessary libraries and features exist on the target system, and the ability to do this has made distribution of OSS much simpler than in the past.
As configure scripts consist of many checks, the attackers had included what appeared to be a check, but was actually a backdoor program. The backdoor program gets saved to a file, compiled, executed, and then both the source and the compiled program get deleted. The only evidence of a successful attack is the running program and the hourly attempts it makes to contact a remote server.
If the connection to the remote server is successful, the backdoor program then executes a shell (command interpreter) that runs with the same privileges as the person who had been installing the software (executing the configure script). The remote attacker needed to have a server running, with its output appearing in a window, and then manually continue the attack once the connection appeared. Backdoors like this have the great advantage of making an outgoing connection--something rarely prevented by firewalls (see my August 2002 NetDef column).
Users of OSS can protect themselves against modified source by taking advantage of GPG signatures associated with most OSS packages. GPG is the successor to PGP (Pretty Good Privacy), the software published by Philip Zimmerman in 1991, and later licensed by NAI. PGP and GPG can be used to digitally sign files, using a private key available only to the signer. Then, anyone who can gain access to the public key of the signer from a trusted site can check the digital signature.
If you have ever visited an OSS site, you have probably seen signature files, and might not have even realized it. Signature files for software packages have the misleading suffix .asc which stands for the ASCII (text) version of the digital signature. The Linux Journal article (see Resources) has information about how to use GPG (or PGP) to check the signatures associated with OSS packages. When the package's signature checks out okay, you know that the package has not been modified since it was signed. You still must trust the person who signed the package, that the signing key has remained secret, and the source code did not contain any backdoors when signed.
TRUSTING TRUST
Which brings us around to the point of should you trust OSS. Should you, or your organization, consider OSS less trustworthy than commercial software? One argument used against OSS is that there cannot be true liability for flaws in OSS because there is no commercial entity to sue. But the most widely used commercial software in use today comes with an End User Licence Agreement (EULA) that stipulates that the user of the software accepts that the software vendor's only warranty is for the media used to distribute the software. So the liability arguement does not hold water.
OSS programmers do not, in general, get paid to write the software that they maintain. These programmers get paid in another way, by becoming well known for writing great software. Including backdoors would destroy the reputation earned with OSS--it would be the kiss of death for that programmer. Even security-related bugs hurt an OSS programmer's reputation.
OSS programmers actually have stronger motivation to produce secure code than do programmers whose work will never be acknowledged because they work for large, companies where their identity will remain unknown. Also, the OSS programmer's work, the source code, gets published, so that the code written gets subjected to peer review. The OSS programmer is not at the beck and call of a marketing department, with its demands for new features and new versions to be shipped at Internet speed. The success of OSS software relies on its ability to perform a task, in a secure fashion, and do so as well or better than a comparable commercial product. Marketing in OSS means that the software works as advertised, and continues to be supported.
OSS provides the tools necessary to use computers. Most of the profit made using computers comes not from the sale of software, but the use of software to produce or sell. OSS has proven to be as secure, or more secure, than commercial software. Just be careful and check the source, and the signature.
RESOURCES:
Reflections on Trusting Trust, 1984 ACM award acceptance speech by Ken Thompson: http://www.acm.org/classics/sep95/
The Easter Egg site page with a variety of Excel backkdoors: http://www.eeggs.com/tree/279.html
Section of Secure Programming book discussing pros and cons of Open
Source Security:
http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO.html#OPEN-SOURCE-SECURITY
Page explaining the consequences of the configure file being modified: http://www.irssi.org/?page=backdoor
Open Source book: http://www.oreilly.com/catalog/opensources/book/brian.html
Article explaining how to use GPG to check the signature file
associated with a downloaded archive:
http://www.linuxjournal.com/article.php?sid=4828
CERT Advisory issued in October 2002 about another configure backdoor, this time in sendmail: http://www.cert.org/advisories/CA-2002-28.html