EXP33-C. Do not reference uninitialized memory

Local, automatic variables can assume unexpected values if they are used before they are initialized. C99 specifies, "If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate" [ISO/IEC 9899:1999]. (See also undefined behavior 10 of Annex J.)

In the common case, on implementations that make use of a program stack, this value defaults to whichever values are currently stored in stack memory. While uninitialized memory often contains zeroes, this is not guaranteed. On implementations that include trap representations, reading an uninitialized object of any type other than unsigned char (including int) may trigger a trap. (See undefined behavior 11 of Annex J.) Consequently, uninitialized memory can cause a program to behave in an unpredictable or unplanned manner, lead to undefined behavior , and can provide an avenue for attack.

Additionally, memory allocated by functions, such as malloc(), should not be used before being initialized as its contents are indeterminate.

In most cases, compilers warn about uninitialized variables, discussed in recommendation MSC00-C. Compile cleanly at high warning levels.

Noncompliant Code Example

In this noncompliant code example, the set_flag() function is intended to set the variable sign to -1 when number is negative or 1. However, the programmer neglected to account for number being 0. If number is 0, then sign remains uninitialized. Because sign is uninitialized, assuming that the architecture makes use of a program stack, it uses whatever value is at that location in the program stack. This may lead to unexpected or otherwise incorrect program behavior.

void set_flag(int number, int *sign_flag) {
  if (sign_flag == NULL)
    return;

  if (number > 0)
    *sign_flag = 1;
  else if (number < 0)
    *sign_flag = -1;
}

int is_negative(int number) {
  int sign;

  set_flag(number, &sign);

  return sign < 0;
}

Compilers assume that when the address of an uninitialized variable is passed to a function, the variable is initialized within that function. Because compilers frequently fail to diagnose any resulting failure to initialize the variable, the programmer must apply additional scrutiny to ensure the correctness of the code.

Compliant Solution

This defect results from a failure to consider all possible data states. (See recommendation MSC01-C. Strive for logical completeness.) Once the problem is identified, it can be trivially repaired by accounting for the possibility that number can be equal to 0.

Note also that unless doing so is prohibitive for performance reasons, an additional defense-in-depth practice worth considering is to initialize local variables immediately after declaration. While compilers and static analysis tools often detect uses of uninitialized variables when they have access to the source code, diagnosing the problem is difficult or impossible when either the initialization or the use takes place in object code the source code of which is inaccessible to the tool.

void set_flag(int number, int *sign_flag) {
  if (sign_flag == NULL)
    return;

  if (number >= 0) { /* account for number being 0 */
    *sign_flag = 1;
  }
  else {
    assert(number < 0);
    *sign_flag = -1;
  }
}

int is_negative(int number) {
  int sign = 0;   /* initialize as a matter of defense-in-depth */

  set_flag(number, &sign);

  return sign < 0;
}

Noncompliant Code Example

In this noncompliant code example, the programmer mistakenly fails to set the local variable error_log to the msg argument in the report_error() function [Mercy 2006]. Because error_log has not been initialized, on architectures making use of a program stack, it assumes the value already on the stack at this location, which is a pointer to the stack memory allocated to the password array. The sprintf() call copies data in password until a null byte is reached. If the length of the string stored in the password array is greater than the size of the buffer array, a buffer overflow occurs.

#include <stdio.h>
#include <ctype.h>
#include <string.h>

int do_auth(void) {
  char *username;
  char *password;

  /* Get username and password from user, return -1 if invalid */
}

void report_error(const char *msg) {
  const char *error_log;
  char buffer[24];

  sprintf(buffer, "Error: %s", error_log);
  printf("%s\n", buffer);
}

int main(void) {
  if (do_auth() == -1) {
    report_error("Unable to login");
  }
  return 0;
}

Noncompliant Code Example

In this noncompliant code example, the report_error() function has been modified so that error_log is properly initialized.

void report_error(const char *msg) {
  const char *error_log = msg;
  char buffer[24];

  sprintf(buffer, "Error: %s", error_log);

  printf("%s\n", buffer);
}

This solution is still problematic because a buffer overflow will occur if the null-terminated byte string referenced by msg is greater than 17 bytes, including the NULL terminator. The solution also makes use of a "magic number," which should be avoided. (See recommendation DCL06-C. Use meaningful symbolic constants to represent literal values.)

Compliant Solution

In this solution, the magic number is abstracted, and the buffer overflow is eliminated.

enum {max_buffer = 24};

void report_error(const char *msg) {
  const char *error_log = msg;
  char buffer[max_buffer];

  snprintf(buffer, sizeof(buffer), "Error: %s", error_log);
  printf("%s\n", buffer);
}

Compliant Solution

A much simpler, less error prone, and better performing compliant solution is shown here:

void report_error(const char *msg) {
  printf("Error: %s\n", msg);
}

Noncompliant Code Example (mbstate_t)

In the noncompliant code example below, the function mbrlen() is passed the address of an automatic mbstate_t object that has not been properly initialized, leading to undefined behavior. See undefined behavior 188 in Section J.2 of C99.

void f(const char *mbs) {
  size_t len;
  mbstate_t state;

  len = mbrlen(mbs, strlen(mbs), &state);

  /* ... */
}

Compliant Solution (mbstate_t)

Before being passed to a multibyte conversion function, an mbstate_t object must be either initialized to the initial conversion state or set to a value that corresponds to the most recent shift state by a prior call to a multibyte conversion function. The compliant solution below sets the mbstate_t object to the initial conversion state by setting it to all zeros.

void f(const char *mbs) {
  size_t len;
  mbstate_t state;

  memset(&state, 0, sizeof state);
  len = mbrlen(mbs, strlen(mbs), &state);

  /* ... */
}

Risk Assessment

Accessing uninitialized variables generally leads to unexpected program behavior. In some cases, these types of flaws may allow the execution of arbitrary code.

Distributions derived from Debian, particularly VU#925211 in the OpenSSL package for Debian Linux, are said to reference uninitialized memory. One might say that uninitialized memory causes the vulnerability, but this is not entirely true. The original OpenSSL code uses uninitialized memory as an additional source of randomness to an already-randomly-generated key. This generates good keys, but also causes the code-auditing tools Valgrind and Purify to issue warnings. Debian tries to fix the warnings with two changes. One actually eliminates the uninitialized memory access, but the other weakens the randomness of the keys.

Automated Detection

Related Vulnerabilities

CVE-2009-1888 results from a violation of this recommendation. Some versions of SAMBA (up to 3.3.5) call a function which takes in two potentially unitiliazed variables involving access rights. An attacker can exploit this to bypass the access control list and gain access to protected files [xorl 2009].

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

Related Guidelines

CERT C++ Secure Coding Standard: EXP33-CPP. Do not reference uninitialized memory

ISO/IEC 9899:1999 Section 6.7.8, "Initialization"

ISO/IEC TR 24772 "LAV Initialization of Variables"

Bibliography

[Flake 2006]
[Mercy 2006]
[xorl 2009] "CVE-2009-1888: SAMBA ACLs Uninitialized Memory Read"