ENV03-A. Sanitize the environment before invoking external programs

Many programs and libraries, including the shared library loader on both Unix and Windows systems, depend on environment variable settings. Because environment variables are inherited from the parent process when a program is executed, an attacker can easily sabotage variables, causing a program to behave in an unexpected and insecure manner [[Viega 03]].

Attackers can manipulate environmental variables to trick an executable into running a spoofed version of a shared library or executable. Most modern systems, for example, use dynamic libraries and most executables are dynamically linked (that is, use dynamic libraries). An attacker can run arbitrary code with the privileges of a spoofed process by installing a spoofed version of a shared library and influencing the mechanism for dynamic linking by setting the LD_PRELOAD environmental variable (or another LD_* environmental variable). An interesting example of this vulnerability involving the RFC 1408/RFC 1572 Telnet Environment Option is documented in CERT Advisory CA-1995-14, "Telnetd Environment Vulnerability" [CA-1995-14]. The Telnet Environment Option extension to telnet supports the transfer of environment variables from one system to another, allowing an attacker to transfer environment variables that influence the login program called by the telnet daemon and bypass the normal login and authentication scheme to become root on that system.

Certain variables can cause insecure program behavior if they are missing from the environment or improperly set. As a result, the environment cannot be fully purged. Instead, variables that should exist should be set to safe values or treated as untrusted data and examined closely before being used.

For example, the IFS variable (which stands for "internal field separator") is used by some shells to determine which characters separate command line arguments.  A shell has the option of using the incoming IFS value or resetting it to its default at the time the shell is invoked.  Because the shell is invoked by the C99 system() function and the POSIX popen() function, setting IFS to unusual values can subvert apparently-safe calls.

Environment issues are particularly dangerous with setuid/setgid programs because an attacker can completely control the environment variables.

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.

system("/bin/ls dir.`date +%Y%m%d`");

When the default shell does not ignore the incoming value of the IFS environment value, 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 an attacker sets IFS to "." the intended directory will not be found.

Compliant Solution (POSIX) (ls)

Sanitize the environment by setting required variables to safe values and removing extraneous environment variables. Set IFS to its default of "{{ \t\n}}" (the first character is a space character). Set the PATH environment variable to the string returned by calling confstr() with the first argument _CS_PATH. Preserve the TZ environment variable (if present) which denotes the time zone (see the Open Group Base Specifications Issue 6 specifies for the format for this variable [[Open Group 04]].

One way to clear the environment is to use the clearenv() function. The function clearenv() has an odd history; it was supposed to be defined in POSIX.1, but never made it into the standard. However, it is defined in POSIX.9 (the Fortran 77 bindings to POSIX), so there is a quasi-official status for it [[Wheeler 03]].

The other technique is to directly manipulate the environment through the environ variable. According to the Open Group Base Specifications Issue 6 [[Open Group 04]]:

The value of an environment variable is a string of characters. For a C-language program, an array of strings called the environment shall be made available when a process begins. The array is pointed to by the external variable environ, which is defined as:

extern char **environ;

These strings have the form name=value; names shall not contain the character '='.

Note that C99 standard states that "The set of environment names and the method for altering the environment list are implementation-defined."

Compliant Solution (Sanitization)

If you explicitly know which environment variables you want to keep, the function below adapted from [[Viega 03]] will remove everything else.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

extern char **environ;

/* These arrays are both null-terminated. */
static char *spc_restricted_environ[  ] = {
  "IFS= \t\n",
  0, /* leave room for PATH=... */
  0
};

static char *spc_preserve_environ[  ] = {
  "TZ",
  0
};

void spc_sanitize_environment(int preservec, const char **preservev) {
  int    i;
  char   **new_environ, *path, *ptr;
  const char *value, *var;
  size_t path_size, arr_size = 1, arr_ptr = 0, len, new_size = 0;

  if ((path_size = confstr(_CS_PATH, NULL, 0)) > 0) {
    path = (char *)malloc(path_size + sizeof("PATH=") - 1);
    if (path == NULL) {
      /* handle error */
    }
    strcpy(path, "PATH=");
    if (confstr(_CS_PATH, path + sizeof("PATH=") - 1, path_size) > 0) {
      spc_restricted_environ[1] = path;
    }
    else {
      free(path);
      path = NULL;
    }
  }
  for (i = 0;  (var = spc_restricted_environ[i]) != 0;  i++) {
    new_size += strlen(var) + 1;
    arr_size++;
  }
  for (i = 0;  (var = spc_preserve_environ[i]) != 0;  i++) {
    if ((value = getenv(var)) == NULL) continue;
    new_size += strlen(var) + strlen(value) + 2; /* include the '=' */
    arr_size++;
  }
  if (preservec && preservev) {
    for (i = 0;  i < preservec && (var = preservev[i]) != 0;  i++) {
      if ((value = getenv(var)) == NULL) continue;
      new_size += strlen(var) + strlen(value) + 2; /* include the '=' */
      arr_size++;
    }
  }

  new_size += (arr_size * sizeof(char *));
  if ((new_environ = (char **)malloc(new_size)) == NULL) abort(  );
  new_environ[arr_size - 1] = 0;

  ptr = (char *)new_environ + (arr_size * sizeof(char *));
  for (i = 0;  (var = spc_restricted_environ[i]) != 0;  i++) {
    new_environ[arr_ptr++] = ptr;
    len = strlen(var);
    memcpy(ptr, var, len + 1);
    ptr += len + 1;
  }
  for (i = 0;  (var = spc_preserve_environ[i]) != 0;  i++) {
    if ((value = getenv(var)) == NULL) continue;
    new_environ[arr_ptr++] = ptr;
    len = strlen(var);
    memcpy(ptr, var, len);
    *(ptr + len + 1) = '=';
    memcpy(ptr + len + 2, value, strlen(value) + 1);
    ptr += len + strlen(value) + 2; /* include the '=' */
  }
  if (preservec && preservev) {
    for (i = 0;  i < preservec && (var = preservev[i]) != 0;  i++) {
      if ((value = getenv(var)) == NULL) continue;
      new_environ[arr_ptr++] = ptr;
      len = strlen(var);
      memcpy(ptr, var, len);
      *(ptr + len + 1) = '=';
      memcpy(ptr + len + 2, value, strlen(value) + 1);
      ptr += len + strlen(value) + 2; /* include the '=' */
    }
  }

  /* new_environ can now be used as the envp argument to execle or execve */
}

POSIX.1-2008 [[Austin Group 08]] defines a new _CS_V7_ENV argument to confstr() to retrieve a list of environment variable settings required for a default conforming environment.  A space-separated list of variable=value pairs is returned, with variable names guaranteed not to contain = signs, and variable=value pairs guaranteed not to contain spaces.  Used together with the _CS_PATH request illustrated above, this completely describes the minimum environment variable settings required to obtain a clean conforming environment.  On systems conforming to the POSIX.1-2008 standard, this should be used to create a sanitized environment.

Non-Compliant Code Example (POSIX) (grep)

This non-compliant code invokes the C99 system() function to perform a user-specified search using one of the standard grep programs. The user specifies the files searched, the search pattern, the options to grep, and, in fact, the variant; they could use fgrep, for instance.

char* search_command; /* provided by the user, looks like 'grep -e...' */
system( search_cmmand);

In this scenario, the user may actually issue any command, (or multiple commands!) to be arbitrarily executed by the system.

Compliant Solution (POSIX) (grep)

In this compliant solution, the user again supplies the command string, but the system ensures that nothing is called except grep, fgrep, or egrep. Also, the system ensures the environment is sanitized, and that no extra commands are supplied.

Rather simplistically, the sanitization of the command is done by eliminating 'dangerous' characters, including ` and ;, that can be used to embed other commands. This sanitization will most likely result in an invalid command, but this is still more secure than executing arbitrary commands.

#include <string.h>

/* ... */
char* search_command; /* provided by the user, looks like 'grep -e...' */

if (strlen( search_command) < strlen("xgrep")) {
   /* handle too-short-command error */
}

{
  /* Make sure command is actually a grep variant
   * by ensuring command starts with "grep" or "*grep" */
  char* location = strstr( search_command, "grep");
  if (location != search_command && location != search_command+1) {
    /* handle not-a-grep-command error */
  }
}

{
  /* Eliminate bad chars */
  static char bad_chars[] = ";`";
  char *cp; /* cursor into string */
  for (cp = search_command; *(cp += strcspn(cp, bad_chars)); ) {
    *cp = ' ';
  }
}

/* Sanitize environment, from previous compliant example  */
spc_sanitize_environment(0, NULL);

if (system( search_cmmand) != 0) {
  /* handle system error */
}

This example uses the spc_sanitize_environment() from the previous example to ensure the environment is 'clean' before issueing the command. It also sanitizes the command string, which is described in STR02-A. Sanitize data passed to complex subsystems.

Since this program uses system(), one should consider alternatives as per ENV04-A. Do not call system() if you do not need a command processor, however this particular example does require a command interpreter.

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]] vol. 2, System Interfaces, confstr()
[[Dowd 06]] Chapter 10, "UNIX II: Processes"
[[ISO/IEC 9899-1999]] Section 7.20.4, "Communication with the environment"
[[Open Group 04]] Chapter 8, "Environment Variables"
[[Viega 03]] Section 1.1, "Sanitizing the Environment"
[[Wheeler 03]] Section 5.2, "Environment Variables"

ENV02-A. Beware of multiple environment variables with the same name      11. Environment (ENV)       ENV04-A. Do not call system() if you do not need a command processor