Most UNIX systems now contain user limits to prevent some of these attacks. The Berkeley quota system is designed to prevent someone from consuming too much free disk space. If the quota is large, and the amount of free disk space in /tmp is small, you can still launch a denial-of-service attack. Other limits include those for memory, the number of simultaneously opened files, the number of concurrent processes, and similar constraints for commonly used resources. Unfortunately, these checks are made against the effective UID (EUID), and a user can bypass checking by running SUID or SGID programs that can cause resource exhaustion.

Internal Privilege Escalation

UNIX and NT systems both provide ways for users to gain increased privileges through program execution. NT uses its access rights mechanism, and UNIX relies on the now familiar SUID or SGID concepts. Even if the privileged program does not give the user access to everything on the system, even a little privilege boost can help. For one thing, if the average UNIX user can gain privileges of the mail group by exploiting a SGID mail program, then that user will have access to the mail spool directory. Denial-of-service attacks, or worse, are then possible.

Privileged programs are compromised in a number of ways:

•  The program does not check buffer limits and is subject to a buffer overflow attack.

•  The program does not check input parameters and is tricked into executing one of the parameters as a command (test.cgi hack).

•  The program makes invalid assumptions about its environment.

•  The program is tricked into operating on a different resource because of poor programming practices.

The first two attacks have been discussed previously. A program that makes invalid environment assumptions is poorly written. The classic example is a program that does not set its own PATH environment variable or does not use fully qualified path names for the programs it calls. If a privileged program contains an instruction that tells it to run another program, such as the following, the hacker will install a program with the desired behavior into a writable directory and then invoke the privileged program:

system (“ls -l”);

Instead of running /bin/ls, the privileged program runs the bogus version planted. This problem is so well known that you would expect it to be rare. However, if you were to spend some time digging in commercial operating systems, you might be surprised at how often this poor programming practice still occurs.

UNIX programs also are impacted by inheritance. When a child process is created, it inherits the environment of its parent. If a user’s UMASK setting results in the creation of world writable files, and the user runs a SUID or SGID program that does not reset UMASK, files created by the program will be world writable. If the program treats the file as a cache, writing values into it and reading values from it, then any user will be able to supply chosen data values to the program.

This last type of compromise of privileged programs is especially fun. The idea is really simple. A program reads a parameter, such as a file name, that tells the program which resource to access. The program has a handle to the resource. Before the program accesses the resource, an adversary is somehow able to replace the resource with a different target. Here is a practical example.

The first line of a shell script in UNIX tells the system which shell interpreter to use. A race condition exists in that the kernel looks at this first line and picks out the shell interpreter. The kernel then starts the interpreter with UID and GID according to the SUID and SGID permission bit settings for the file. Before the kernel feeds the script’s statements to the interpreter, the file’s contents can be replaced. This is a well-known race condition. You might think this last step is impossible unless you have write access to the shell script file. However, you can create a symbolic link from the SUID or SGID shell script in your current directory, start the script, and replace the file in your current directory with anything of your choosing before the commands are fed to the interpreter. You can use other tricks to broaden the window of opportunity for exploiting the race condition. If the shell script is not privileged, this hack does nothing exciting. For shell scripts with SUID or SGID bits set, the result is that the hacker will be able to run any shell commands with the EUID and EGID of the owner of the symbolic link. As a general rule, you should not have SUID or SGID shell scripts on your systems.

Internal Superuser Privileges

The biggest threat to a system is when a user gains superuser or complete administrative privileges. The same kinds of attacks and problems mentioned previously apply for root or administrator privileged programs. Buffer overflow attacks, data-driven attacks, spoofed resources, and spoofed network packets have all been exploited by normal users to gain privileged access to a system.

Will a firewall prevent these privilege escalations from happening? Well, if the network attack is like the test.cgi attack, and the Web server is running as root or Administrator, then the firewall will not help. Do people actually run Web servers as root?

Many systems now support HTML interfaces for system administrator tasks. The HTML pages launch CGI programs that must run with root privileges because they do things the root user normally would do from the command line. The only way to accomplish this is by running the httpd daemon as root so that it can spawn CGI processes with these same privileges. If a user on the internal network is able to send in an HTTP packet to the Web server running as root, the server can be tricked into executing arbitrary commands.

If you have seen any of these privileged Web servers, you know that as a first step, the person connecting to the server must authenticate using a user ID and password. The Web pages are protected with standard Web server access control rules. When authentication is complete, the httpd daemon will respond to requests without requiring additional authentication. An attacker can spoof the IP address of the administrator’s station and send arbitrary HTTP commands to the privileged Web server. This attack is hopefully not possible from the outside because a properly configured network will not permit external access to a Web server running as root. However, because this same node might be an internal data server, most users will have access to it, meaning that the threat of forged packets is real. To avoid attacks against Web servers running as root, use SSL or IPsec to prevent network node impersonation.