The purpose of this article is to show how basic security principles can help you develop programs that are harder for the bad guys to break. We'll examine a simple function that executes a command as though it were typed at the keyboard, exactly what the library function system does. But unlike many system implementations, we'll constrain what happens so the calling program can't trick it into executing some other program.

The system function takes a single argument: a character string with the command to be executed just as it would be typed at the keyboard. The function first invokes the Bourne shell, passing the command to that shell using the "–c" option. The shell then spawns the command. For example:

system("date")
invokes the command
/bin/sh –c "date"

This executes the program "date," which prints the date on the standard output.

Security Issues
Security issues arise when the program invoking the system function is a privileged program. The "privilege" may consist of having setuid and/or setgid privileges such as su or being able to run one of a specified set of programs such as a Web server serving CGI scripts. The attacker's goal is to trick the program into executing some other program, for example a version of date that's a command interpreter rather than just printing the date.

Problems arise because of the power of the Bourne shell as a command interpreter. That shell takes information from the environment, which consists of shell variables, file descriptors, signal-handling routines, and any other aspects of the process space that could affect program execution. For our purposes, we'll just consider environment variables.

One relevant environment variable is the PATH environment variable. When given a command that doesn't contain a '/' the Bourne shell treats the value of the PATH variable as a sequence of directory names. It looks in each directory in the given order for a program named "date" and executes the first one found. Suppose an attacker finds a setuid-to-root program that uses system to run the "date" command. The attacker can then copy the shell into a file named "date" in her current working directory, prepend "." to the list of directories in the value of PATH, and then execute the program. When system invokes the shell, it searches each directory in the value of PATH in order for a command named "date." The first directory searched will be the current working directory. The shell will find a program called "date" there and execute it, spawning the command interpreter, which will run with root privileges.

Our goal is to construct a version of system that's invulnerable to this kind of attack. Specifically, we want to guarantee that when the caller passes a command name to system, the user can't cause the program to execute a different program.

Applying the Principles
We'll apply two principles of secure design and implementation. They come from a paper by Jerome Saltzer and Michael Schroeder and are central to any security work. In practice, we would also consider the other six, but the two we'll use have more impact on the design and implementation of this particular function than the others.

Principle of Least Privilege
The first principle is the principle of least privilege. This principle, also called the need-to-know principle, says that a process should have the minimum privileges needed to perform its task. For this problem, this rule says that system should execute the command with the privileges of the user, not with those of root, if at all possible. As an example, were the privileged program to print the date and time by using system to run the command "date" as described above, there's no reason that "date" needs to be executed as root. It could just as easily be executed with the user's privileges. Hence the first step in our new system command would be to let the caller reset the privileges to those of the real user and group. Doing this means that the user can only compromise her own account - and as since she already has full access to it such a compromise is meaningless.

If the caller lets the user select one of a set of commands, then a different application of the principle of least privilege provides the required restriction. The program configuration should create a directory into which copies of the commands to be executed are placed. Then the program changes its notion of the root directory to that of the directory containing the commands. Even if the user can enter the name of a different command, only the authorized commands are accessible to the program. So only the authorized commands can be executed, and the user will get an error message. This is the technique that sendmail's restricted shell uses to ensure that sendmail only executes safe programs like procmail and vacation. Web servers should use this technique to ensure that commands to execute CGI programs can only execute the CGI programs in the Web server's directories.

Principle of Fail-Safe Defaults
The principle of fail-safe defaults says that access to resources and objects should be denied by default. If you need access to only one particular object, the usual approach of removing access to all other objects violates this principle. Instead, access to all objects should be removed, and then access privileges for that particular object should be explicitly granted. The distinction is subtle, but critical.

To see this, consider the problem of ensuring the user's PATH environment variable is set appropriately. The naive approach is to search the environment for the PATH environment variable and check that its value is acceptable. This leads to two problems. First, what happens if the value is not acceptable? In this case, the value must be replaced. Second, what happens if there are multiple occurrences of the variable? The values of all must be checked and found satisfactory, or all but one must be deleted.

A second approach is to require that the program use the full path name of the program. So the invocation of the system call would be:

system("/bin/date")

This causes the shell to ignore the PATH setting. Unfortunately, this approach is also flawed.

Environment variables other than PATH affect the executed program. For some versions of the Bourne shell, the value of the environment variable IFS is a string of characters that the shell treats as word separators. (This is particularly useful when a shell script is reading lines from the password file, for example.) In such a shell, the following command prints files X and Y:

IFS="/$IFS"; export IFS; cat/x/y

because the shell sees the "/" character as a word separator, which lets the user thwart the use of a full path name as described above. All she need do is set IFS in her environment to include the "/" character and then create a program called "bin" in her current working directory. She then changes her PATH environment variable to look in the current working directory first. When she runs the command, the privileged program invokes the above system function. The subordinate shell reads the argument of system as having two words, "bin" followed by the argument "date." Hence the user's program "bin" will be executed and the shell will pass "date" to it as an argument.

Again the programmer can try to prevent this by setting IFS explicitly in the environment:

system("IFS=\" \t\n\"; export IFS; /bin/date")

As tempting as this approach is, it suffers from two problems. The first is that the attacker can easily defeat it by adding "I" to the IFS variable. Then the shell sees this as adding the environment variable FS to the environment. The second problem arises when the attacker doesn't do this. There are now two occurrences of the IFS environment variable in the environment. Which one is used? That turns out to be implementation-dependent: some versions of the shell use the first (the user's), and others use the second (the one defined in the system argument.

Following the principle of fail-safe defaults offers a simple answer to all this. First, create an empty environment for the shell. Then add preset, safe values of PATH, IFS, and any other needed environment variables to that environment. Finally, set the shell's environment to be the newly created one. Doing so makes the user's environment irrelevant to the system function and the shell it calls. The shell never refers to the user's environment. The shell only uses the newly created safe environment.

Now the order in which the shell evaluates the variables in the environment is irrelevant, because there is only one occurrence of each variable in the environment. If the user adds "/" to the value of IFS in her environment, or alters the value of the PATH environment variable, the shell ignores those changes because it never sees the values of those variables. It only sees the ones defined in the environment set up by the program.

Conclusion
Programming with security in mind is critical for today's programs. This style of programming requires a methodical approach, not one in which various tricks are used without understanding how and why they work. The problem is that tricks only apply to certain situations, and can only be used effectively if those situations arise. But the principles of secure design and implementation apply always, and dramatically improve both the quality and the security of the programs and systems they are applied to.

Recommended Reading