Holes in the Armor 245 Superuser: The Superflaw All multiuser operating systems need privileged accounts. Virtually all multiuser operating systems other than Unix apportion privilege according to need. Unix’s “Superuser” is all-or-nothing. An administrator who can change people’s passwords must also, by design, be able to wipe out every file on the system. That high school kid you’ve hired to do backups might accidentally (or intentionally) leave your system open to attack. Many Unix programs and utilities require Superuser privileges. Complex and useful programs need to create files or write in directories to which the user of the program does not have access. To ensure security, programs that run as superuser must be carefully scrutinized to ensure that they exhibit no unintended side effects and have no holes that could be exploited to gain unauthorized superuser access. Unfortunately, this secu- rity audit procedure is rarely performed (most third-party software vendors, for example, are unwilling to disclose their sourcecode to their customers, so these companies couldn’t even conduct an audit if they wanted). The Problem with SUID The Unix concept called SUID, or setuid, raises as many security problems as the superuser concept does. SUID is a built-in security hole that provides a way for regular users to run commands that require special privileges to operate. When run, an SUID program assumes the privileges of the person who installed the program, rather than the person who is running the pro- gram. Most SUID programs are installed SUID root, so they run with supe- ruser privileges. The designers of the Unix operating system would have us believe that SUID is a fundamental requirement of an advanced operating system. The most common example given is /bin/passwd, the Unix program that lets users change their passwords. The /bin/passwd program changes a user’s password by modifying the contents of the file /etc/passwd. Ordinary users can’t be allowed to directly modify /etc/passwd because then they could change each other's passwords. The /bin/passwd program, which is run by mere users, assumes superuser privileges when run and is constructed to change only the password of the user running it and nobody else’s. Unfortunately, while /bin/passwd is running as superuser, it doesn’t just have permission to modify the file /etc/passwd: it has permission to mod- ify any file, indeed, do anything it wants. (After all, it’s running as root, with no security checks). If it can be subverted while it is running—for example, if it can be convinced to create a subshell—then the attacking user can inherit these superuser privileges to control the system.

246 Security AT&T was so pleased with the SUID concept that it patented it. The intent was that SUID would simplify operating system design by obviating the need for a monolithic subsystem responsible for all aspects of system secu- rity. Experience has shown that most of Unix's security flaws come from SUID programs. When combined with removable media (such as floppy disks or SyQuest drives), SUID gives the attacker a powerful way to break into otherwise “secure” systems: simply put a SUID root file on a floppy disk and mount it, then run the SUID root program to become root. (The Unix-savvy reader might object to this attack, saying that mount is a privileged command that requires superuser privileges to run. Unfortunately, many manufacturers now provide SUID programs for mounting removable media specifically to ameliorate this “inconvenience.”) SUID isn’t limited to the superuser—any program can be made SUID, and any user can create an SUID program to assume that user’s privileges when it is run (without having to force anybody to type that user’s password). In practice, SUID is a powerful tool for building traps that steal other users’ privileges, as we’ll see later on. The Cuckoo’s Egg As an example of what can go wrong, consider an example from Cliff Stoll’s excellent book The Cuckoo’s Egg. Stoll tells how a group of com- puter crackers in West Germany broke into numerous computers across the United States and Europe by exploiting a “bug” in an innocuous utility, called movemail, for a popular Unix editor, Emacs. When it was originally written, movemail simply moved incoming pieces of electronic mail from the user’s mailbox in /usr/spool/mail to the user’s home directory. So far, so good: no problems here. But then the program was modified in 1986 by Michael R. Gretzinger at MIT’s Project Athena. Gretzinger wanted to use movemail to get his electronic mail from Athena’s electronic post office running POP (the Internet Post Office Protocol). In order to make movemail work properly with POP, Gretzinger found it necessary to install the program SUID root. You can even find Gretzinger’s note in the movemail source code: /* * Modified January, 1986 by Michael R. Gretzinger (Project Athena) * * Added POP (Post Office Protocol) service. When compiled -DPOP * movemail will accept input filename arguments of the form * "po:username". This will cause movemail to open a connection to * a pop server running on $MAILHOST (environment variable). * Movemail must be setuid to root in order to work with POP.