Holes in the Armor 247 * * ... */ There was just one problem: the original author of movemail had never suspected that the program would one day be running SUID root. And when the program ran as root, it allowed the user whose mail was being moved to read or modify any file on the entire system. Stoll’s West Ger- man computer criminals used this bug to break into military computers all over the United States and Europe at the behest of their KGB controllers. Eventually the bug was fixed. Here is the three-line patch that would have prevented this particular break-in: /* Check access to output file. */ if (access(outname,F_OK)==0 && access(outname,W_OK)!=0) pfatal_with_name (outname) It’s not a hard patch. The problem is that movemail itself is 838 lines long—and movemail itself is a minuscule part of a program that is nearly 100,000 lines long. How could anyone have audited that code before they installed it and detected this bug? The Other Problem with SUID SUID has another problem: it give users the power to make a mess, but not to clean it up. This problem can be very annoying. SUID programs are (usually) SUID to do something special that requires special privileges. When they start acting up, or if you run the wrong one by accident, you need a way of killing it. But if you don’t have superuser privileges your- self, you are out of luck: Date: Sun, 22 Oct 89 01:17:19 EDT From: Robert E. Seastrom rs@ai.mit.edu To: UNIX-HATERS Subject: damn setuid Tonight I was collecting some info on echo times to a host that’s on the far side of a possibly flakey gateway. Since I have better things to do than sit around for half an hour while it pings said host every 5 seconds, I say: % ping -t5000 -f 60 host.domain logfile &

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).