Writing to a Privileged Resource

A number of publicized attacks against SUID root programs take advantage of a race condition that demonstrates abuse of write privileges. If the SUID program creates a world-writable file in /tmp, for example, you can replace the file with a symbolic link to a world-readable resource such as /etc/passwd. This trick can cause the SUID program to write into a resource that it had no intention of altering. The X Windows server on some systems will create temporary world-writable files in the /tmp directory. Even the sticky bit will not prevent someone from creating a link from this file to another. The sticky bit set by default on /tmp prevents someone from deleting the file.

The creation of world-writable files by privileged programs is an example of poor programming assumptions. Like the PATH problem mentioned before, the programmer made incorrect assumptions about the environment. If the SUID root program inherits its environment from the user’s shell, it should not make any assumptions about PATH, UMASK, or any other environment variable. To avoid these problems, monitor your system for creation of a world-writable file by any user.

Reading a Privileged Resource

If the SUID program consists of only read operations, the goal is to trick the program into reading another privileged file that it had no intention of accessing. For example, if you can somehow trick the program into divulging the contents of the shadow password file, you can copy this output and run crack against it later. Access to other privileged files can reveal credit card numbers, account balances, or other secret information that you can use for destructive purposes, such as blackmail. Low-level access to disk drives is sufficient for reading any of the disk’s contents because the read operations bypass the file-system permissions altogether. Treat read threats with respect.

The trick to detecting when a privileged resource has been compromised is to look for audit events on these resources when the AUID is someone other than the resource’s owner or root. If a normal user’s AUID appears in the read of a privileged resource, you could have problems. Unfortunately, you cannot merely search for any occurrence of a nonroot AUID in an operation on a privileged resource. When you change your password, the passwd program is SUID root, and the event in the audit trail shows a change to the shadow password file with your AUID. You also will need to consider the program name that appears in the event. If you recall, SeOS enables you to define which program paths can be used to access particular system resources. Although not part of commercial IDSs today, this expressibility in a signature would be useful.

Running a Command

If the program does not read any user input into buffers, the chances of executing a buffer overflow attack against it are slim. The only way to possibly sneak in a buffer overflow attack is to somehow modify the name or contents of a resource that the privileged program is accessing in the hopes that a boundary problem will be found. This attack is unlikely because many of the resources are privileged in the first place, and if the hacker could access them, another fruitful hole must exist elsewhere.

The attack that has been in vogue for quite a while is the buffer overflow attack. This is not surprising because so many privileged programs seem to be vulnerable. In principle, the buffer overflow attack is easy to detect. A SUID root program does something it should not be doing, such as forking or exec of a shell. In practice this pattern is difficult to express in general enough terms to catch all attacks. Privilege escalations occur many times during the day on a system, and in each event record, the user’s AUID and RUID remain the same, but the EUID changes to that of the privileged user. Some individual patterns that work are as follows:

•  Detect when a program is run that shows a privilege escalation (EUID becomes 0), and this program next forks or execs /bin/sh, /bin/csh, /bin/tsh, /bin/ksh, or some other shell.

•  Detect when a privilege escalation occurs, followed by the copying of a program, followed by setting the program’s owner to be root, followed by setting the execute bit for the file, finally followed by setting the SUID bit for the program.

Detecting a large set of buffer overflow attacks requires knowing which SUID programs legitimately fork or exec other programs and then watching for all other cases. In other words, you need to know for every SUID and SGID program what the possible valid transitions are to other programs. Yikes! It’s unlikely a single person anywhere is able to specify these details for an entire operating system.

Some cases are intuitively obvious. The passwd program should not spawn a shell. SUID or SGID programs that can create a subshell are dangerous anyway. (Sendmail has been attacked this way in the past.) For the time being, you can detect the most common buffer overflow scenarios by watching for the two sequences mentioned previously. By the way, no commercial tools today detect or prevent all buffer overflow attacks. It’s a nontrivial problem to solve.

Another approach is to watch for single events, such as the following:

•  When anyone sets the SUID or SGID bit for a program

•  When AUID != 0 copies a file from one of the system directories (or tries to copy a file and fails)

Creating SUID or SGID programs is something that should not happen very often on your systems, and you probably want to know about it even if it is not an attack.

Other System-Level Attacks to Monitor

You want to monitor several other events on your system, whether the result is successful or not:

•  Attempts to write, link, or delete in the system directories by a nonprivileged AUID

•  Attempts to modify resources such as the system time, /dev/kmem, or /dev/mem

•  Attempts to modify the audit subsystem configuration

•  Attempts to stop the audit subsystem

•  Attempts to run known rogue programs such as zap, crack, SATAN, COPS, and others

•  Attempts to enable an adapter for promiscuous mode (for sniffing the network)

•  Attempts to run exploratory programs (who, rwho, finger, ps, or find)

•  Attempts by unprivileged users to run privileged programs such as mount, exportfs, mknod, and so on

A simple principle to follow when defining a monitoring policy is to watch for any attempts by users to access resources that they should not be referencing. Stalker, for example, will report failed access attempts for resources when the event’s AUID and the resource owner ID are not identical.