Page History

...

All programs, in particular those running with higher privileges than the caller (such as those with setuid/setgid flags), should treat their environment as untrusted user input. Since Because the environment is inherited by processes spawned by calls to the fork(), system(), or exec() functions, it is important to verify that the environment does not contain any values that could lead to unexpected behavior.

The best practice for setuid/setgid such programs is to:

• drop privileges once they are no longer necessary (see POS02-A. Follow the principle of least privilege)
• avoid calling system() (see ENV04-A. Do not call system() if you do not need a command processor)
• if a command processor in absolutely necessary, clear the environment should be cleared out and filled and fill it with trusted or default values (see STR02-A. Sanitize data passed to complex subsystems) before invoking and external program

Because the C99 standard states that "The set of environment names and the method for altering the environment list are implementation-defined." It is important to understand what local functions are available for clearing, modifying, and looking up default values for environment variables. Since Because some programs may behave in unexpected ways when certain environment variables are not set, it is important to understand which variables are necessary on your system and what are safe values for them.

...

If you explicitly know which environment variables you want to keep, \[[Viega 03|AA. C References#Viega 03]\] defines a function which will remove everything else.

Non-Compliant Code Example (POSIX) (ls)

This non-compliant code invokes the C99 system() function to execute the /bin/ls program. The C99 system() function passes a string to the command processor in the host environment to be executed.

...

Although IFS does not affect the command portion of this string, /bin/ls, it does determine how the argument is built after calling date. If the default shell does not ignore the incoming value of the IFS environment value, and an attacker sets IFS to ".", the intended directory will not be found.

Compliant Solution (POSIX) (ls)

In this compliant code example, the environment is first cleared out using clearenv() and then the $PATH and $IFS variables are set to safe values before invoking system().

char *pathbuf;
size_t n;

if (clearenv() != 0) {
  /* Handle Error */
}

n = confstr(_CS_PATH, NULL, 0);
if ((pathbuf = malloc(n)) == NULL) {
  /* Handle Error */
}
confstr(_CS_PATH, pathbuf, n);

if (setenv("PATH", pathbuf, 1) == -1) {
  /* Handle Error */
}
if (setenv("IFS", " \t\n", 1) == -1) {
  /* Handle Error */
}

if (system("/bin/ls dir.`date +%Y%m%d`") == -1) {
  /* Handle Error */
}

Sanitizing a shell command can be difficult, and secure results can adversely impact the inherent power and flexibility associated with shell commands.

Risk Assessment

Invoking an external program in an attacker-controlled environment is dangerous.

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

References

\[[Austin Group 08|AA. C References#Austin Group 08]\] vol. 2, System Interfaces, {{confstr()}}
\[[CA-1995-14|http://www.cert.org/advisories/CA-1995-14.html]\] "Telnetd Environment Vulnerability" 
\[[Dowd 06|AA. C References#Dowd 06]\] Chapter 10, "UNIX II: Processes"
\[[ISO/IEC 9899-1999|AA. C References#ISO/IEC 9899-1999]\] Section 7.20.4, "Communication with the environment"
\[[Open Group 04|AA. C References#Open Group 04]\] Chapter 8, "Environment Variables"
\[[Viega 03|AA. C References#Viega 03]\] Section 1.1, "Sanitizing the Environment"
\[[Wheeler 03|AA. C References#Wheeler 03]\] [Section 5.2, "Environment Variables"|http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/environment-variables.html]

...