Linux and Open-Source Applications

Back doors can easily be embedded in large programs. Occasionally they serve the legitimate function of allowing a manufacturer to perform remote maintenance. But what if a manufacturer embedded a secret door to be used for devious purposes? Would the user even notice?

Programs have certainly become too big for inspection of their executable code for possible security loopholes. More often than not, we don't actually know what a program such as a word processor is doing at any one time—perhaps it is saving a backup copy of the document being typed; perhaps it is scanning the hard disk for credit-card numbers.

Are any of the programs you are running doing tasks you aren't aware of? While writing this article, a prompt appeared on one of the author's screens, informing him that MS Explorer had committed an illegal operation and would be shut down—only he had never explicitly launched Explorer. When starting Visual C++ at home, Windows 95 tries to connect to an ISP. Visual C++ on a machine at work starts without incident, presumably having made the connection through its permanent Ethernet connection to the Internet. If it were not for the first machine, we would never have suspected any network connections were being made.

Early versions of Windows 98 also had an interesting feature. As a result of a programming error, the network registration section passed on system and personal-identification information to the operating system's manufacturer, even if the user explicitly elected not to do so (see Resources 4).

Some versions of Netscape Navigator had an unintended, back-door-style bug first discovered by Cabocomm, a software company located in Aarhus, Denmark (see Resources 5). Web site operators could exploit this error to allow them to upload the contents of any file on the Netscape user's hard disk, making anything on a machine running Netscape 2.x, 3.x or 4.x world-readable to even inexperienced web page creators.

Given the various options discussed so far, what would be the best way to infiltrate as many computers as possible with a data-gathering agent? An ideal vehicle for such a program would be a large application, like Microsoft Office. The overwhelming success of this product has led to its installation in a very high percentage of computer systems. The trick, of course, would be inserting the rogue code into the host program in the first place. Like most corporations, Microsoft would never approve of something like this. However, from the Easter egg examples, we know there are sections of common software packages that definitely did not get corporate approval and can contain substantial functionality.

The unauthorized code could be further hidden by encrypting large portions of it and having some small code fragment decrypt and activate it on demand. An even more flexible technique would be to have a small Easter egg determine if the computer is connected to the Internet, and if so, open a connection to some foreign host. By downloading code from a remote site at runtime, the Easter egg could be tailored to do something to a specific computer or group of computers that wasn't even thought of at the time the original code was created. Perhaps the code would look for computer schematics if the egg was running on a machine inside the ibm.com domain, or automotive sales figures inside gm.com. With browser functionality becoming more and more embedded in operating systems and applications, one more web connection would appear as harmless as the thousands of other web connections continually being made from the victim computer during the course of the day.

The amount of code used by modern programs prevents any manual scrutiny by a few programmers from providing meaningful verification that a program is “safe”. Expert systems, such as those used to track down Y2K problems and conventional viruses, could be used to try to uncover rogue code, but encrypting the implant could render this approach ineffective. Our conclusion is that there is no way a user could effectively scrutinize the object code of an application to determine that it is “safe”. Neither can any software manufacturer.

One possible solution is to make our operating systems more secure. Microsoft Windows NT is a substantial improvement in security from its Windows cousins. NT provides good password security and the ability to regulate access to system resources by different categories of users, and it has generally acceptable network-security features.

What if the OS itself is not safe? We have already suggested that large programs cannot be screened for security violations by programmers or expert systems. The latest operating systems certainly fall into that category, with the result that we cannot be sure the OS itself is not the source of a major security risk. Indeed, most operating systems also contain Easter eggs of one form or another. Thus, there is little point in being concerned about the security risks of application programs if the operating system is suspect.