250 Security run the newly created /tmp/.sh1 to read, delete, or run any of his files with- out the formality of learning his password or logging in as him. If he’s got access to a SUID root shell program (usually called doit), so do you. Con- gratulations! The entire system is at your mercy. Startup traps When a complicated Unix program starts up, it reads configuration files from either the user’s home directory and/or the current directory to set ini- tial and default parameters that customize the program to the user’s specifi- cations. Unfortunately, start up files can be created and left by other users to do their bidding on your behalf. An extremely well-known startup trap preys upon vi, a simple, fast screen- oriented editor that’s preferred by many sysadmins. It’s too bad that vi can’t edit more than one file at a time, which is why sysadmins frequently start up vi from their current directory, rather than in their home directory. Therein lies the rub. At startup, vi searches for a file called .exrc, the vi startup file, in the cur- rent directory. Want to steal a few privs? Put a file called .exrc with the following contents into a directory: !(cp /bin/sh /tmp/.s$$ chmod 4755 /tmp/.s$$)& and then wait for an unsuspecting sysadmin to invoke vi from that direc- tory. When she does, she’ll see a flashing exclamation mark at the bottom of her screen for a brief instant, and you’ll have an SUID shell waiting for you in /tmp, just like the previous attack. Trusted Path and Trojan Horses Standard Unix provides no trusted path to the operating system. We’ll explain this concept with an example. Consider the standard Unix login procedure: login: jrandom password: type your “secret” password When you type your password, how do you know that you are typing to the honest-to-goodness Unix /bin/login program, and not some treacherous doppelganger? Such doppelgangers, called “trojan horses,” are widely available on cracker bulletin boards their sole purpose is to capture your username and password for later, presumably illegitimate, use.

Holes in the Armor 251 A trusted path is a fundamental requirement for computer security, yet it is theoretically impossible to obtain in most versions of Unix: /etc/getty, which asks for your username, and /bin/login, which asks for your pass- word, are no different from any other program. They are just programs. They happen to be programs that ask you for highly confidential and sensi- tive information to verify that you are who you claim to be, but you have no way of verifying them. Compromised Systems Usually Stay That Way Unix Security sat on a wall. Unix Security had a great fall. All the king’s horses, And all the king’s men, Couldn’t get Security back together again Re-securing a compromised Unix system is very difficult. Intruders usually leave startup traps, trap doors, and trojan horses in their wake. After a secu- rity incident, it’s often easier to reinstall the operating system from scratch, rather than pick up the pieces. For example, a computer at MIT in recent memory was compromised. The attacker was eventually discovered, and his initial access hole was closed. But the system administrator (a Unix wizard) didn’t realize that the attacker had modified the computer’s /usr/ucb/telnet program. For the next six months, whenever a user on that computer used telnet to connect to another computer at MIT, or anywhere else on the Internet, the Telnet program captured, in a local file, the victim’s username and password on the remote computer. The attack was only discovered because the computer’s hard disk ran out of space after bloating with usernames and passwords. Attackers trivially hide their tracks. Once an attacker breaks into a Unix, she edits the log files to erase any traces of her incursion. Many system operators examine the modification dates of files to detect unauthorized modifications, but an attacker who has gained superuser capabilities can reprogram the system clock—they can even use the Unix functions specifi- cally provided for changing file times. The Unix file system is a mass of protections and permission bits. If a sin- gle file, directory, or device has incorrectly set permission bits, it puts the security of the entire system at risk. This is a double whammy that makes it relatively easy for an experienced cracker to break into most Unix systems,