In the early days of the MIT Media Lab, there was a graduate student who was very unpopular with the other students in his lab. To protect his privacy, we’ll call the unpopular student “Harry.”

Harry was obnoxious and abrasive, and he wasn’t a very good programmer either. So the other students in the lab decided to play a trick on him. They modified the PL/I compiler on the computer that they all shared so that the program would determine the name of the person who was running it. If the person running the compiler was Harry, the program would run as usual, reporting syntax errors and the like, but it would occasionally, randomly, not produce a final output file.

This mischievous prank caused a myriad of troubles for Harry. He would make a minor change to his program, run it, and—occasionally—the program would run the same way as it did before he made his modification. He would fix bugs, but the bugs would still remain. But then, whenever he went for help, one of the other students in the lab would sit down at the terminal, log in, and everything would work properly.

Poor Harry. It was a cruel trick. Somehow, though, everybody forgot to tell him about it. He soon grew frustrated with the whole enterprise, and eventually left school.^[358]

And you thought those random “bugs” in your system were there by accident?

Perhaps the definitive account of the problems inherent in computer security and trust is Ken Thompson’s article, “Reflections on Trusting Trust.”^[359] Thompson describes a back door planted in an early research version of Unix.

The back door was a modification to the /bin/login program that would allow him to gain superuser access to the system at any time, even if his account had been deleted, by providing a predetermined username and password. While such a modification is easy to make, it’s also an easy one to detect by looking at the computer’s source code. So Thompson modified the computer’s C compiler to detect whether it was translating the login.c program. If so, then the additional code for the back door would automatically be inserted into the object-code stream, even though the code was not present in the original C source file.

Thompson could now have the login.c source inspected by his coworkers, compile the program, install the /bin/login executable, and yet be assured that the back door is firmly in place.

But what if somebody inspected the source code for the C compiler itself? Thompson thought of that case as well. He further modified the C compiler so that it would detect whether it was compiling the source code for itself. If so, the compiler would automatically insert the special login program recognition code. After one more round of compilation, Thompson was able to put all the original source code back in place.

Thompson’s experiment was like a magic trick. There was no back door in the login.c source file and no back door in the source code for the C compiler, and yet there was a back door in both the final compiler and in the login program. Abracadabra!

What hidden actions do your compiler and login programs perform?^[360]

As these examples illustrate, technical expertise combined with superuser privileges on a computer is a powerful combination. Together, they let an attacker change the very nature of the computer’s operating system. An attacker can modify the system to create “hidden” directories that don’t show up under normal circumstances (if at all) and can change the system clock, making it look as if the files that he modified today were actually modified months ago. An attacker can also forge electronic mail. (Actually, anybody can forge electronic mail, but an attacker can do a better job of it.)

Of course, there are some things that an attacker cannot do, even if that attacker is a technical genius and has full access to your computer and its source code. An attacker cannot, for example, decrypt a message that has been encrypted with a perfect encryption algorithm. But he can alter the code to record the key the next time you type it. An attacker probably can’t alter your computer’s hardware to perform basic mathematical calculations a dozen times faster than it currently does, although there are few security implications to doing so. Most attackers can’t read the contents of a file after it’s been written over with another file unless they take apart your computer and take the hard disk to a laboratory. However, an attacker with privileges can alter your system so that deleted files are still accessible (to him).

In each case, how—and when—do you tell if the attack has occurred?

The “what-if” scenario can be taken to considerable lengths. Consider an attacker who is attempting to hide a modification in a computer’s /bin/login program. (See Table 26-1.)

If you think that this description sounds like an intricate game of chess, you’re right. Practical computer security is a series of actions and counteractions, attacks and defenses. As with chess, success depends on anticipating your opponent’s moves and planning countermeasures ahead of time. Simply reacting to your opponent’s moves is a recipe for failure.

The key thing to note, however, is that somewhere, at some level, you need to trust what you are working with. Maybe you trust the hardware. Maybe you trust the CD-ROM. But at some level, you need to trust what you have on hand. Perfect security isn’t possible, so we need to settle for the next best thing: reasonable trust on which to build.

The question is, where do you place that trust?