EXP33-C. Do not reference uninitialized memory

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

In the common case of local, automatic variables being stored on the program stack, their values default to whichever values are currently stored in stack memory. Uninitialized memory often contains—but is not guaranteed to contain—zeros. Uninitialized memory has indeterminate value, which for objects of some types can be a trap representation. Reading uninitialized memory is undefined behavior (see undefined behavior 10 and undefined behavior 12 in Annex J of the C Standard); it can cause a program to behave in an unexpected manner and provide an avenue for attack.

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

In most cases, compilers warn about uninitialized variables, discussed in MSC00-C. Compile cleanly at high warning levels. In other cases, compilers will completely optimize out the uninitialized variables.

Noncompliant Code Example

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

void set_flag(int number, int *sign_flag) {
  if (NULL == sign_flag)
    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 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.

Although 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 for which the source code is inaccessible. Unless doing so is prohibitive for performance reasons, an additional defense-in-depth practice worth considering is to initialize local variables immediately after declaration.

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

  if (number >= 0) { /* Account for number being 0 */
    *sign_flag = 1;
  } else {
    *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, it assumes the value already on the stack at this location (on architectures using a program stack), 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>

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:

#include <stdio.h>
 
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 example 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. It also makes use of a magic number, which should be avoided. (See DCL06-C. Use meaningful symbolic constants to represent literal values.)

Compliant Solution

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

#include <stdio.h>
 
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:

#include <stdio.h>
 
void report_error(const char *msg) {
  printf("Error: %s\n", msg);
}

Noncompliant Code Example (mbstate_t)

In this noncompliant code example, 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 200 in Annex J of the C Standard.

#include <wchar.h>  /* For mbrlen(), mbstate_t, and size_t */
#include <string.h> /* For strlen() */
 
void func(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 sets the mbstate_t object to the initial conversion state by setting it to all zeros.

#include <wchar.h>  /* For mbrlen(), mbstate_t, and size_t */
#include <string.h> /* For strlen() */
 
void func(const char *mbs) {
  size_t len;
  mbstate_t state;

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

  /* ... */
}

Noncompliant Code Example (POSIX, Entropy)

In this noncompliant code example, the process ID, time of day, and uninitialized memory junk is used to seed a random number generator. This behavior is characteristic of some distributions derived from Debian that use uninitialized memory as a source of entropy because the value stored in junk is indeterminate. However, because accessing indeterminate values is undefined behavior, compilers may optimize out the uninitialized variable access completely, leaving only the time and process ID and resulting in a loss of desired entropy.

#include <time.h>
#include <unistd.h>
#include <stdlib.h>
 
void func(void) {
  struct timeval tv;
  unsigned long junk;

  gettimeofday(&tv, NULL);
  srandom((getpid() << 16) ^ tv.tv_sec ^ tv.tv_usec ^ junk);

  /* ... */
}

In security protocols that rely on unpredictability, such as RSA encryption, a loss in entropy results in a less secure system [Wang 2012].

Implementation Details

For this noncompliant code example, OS X 10.6 retains the junk value, but OS X 10.7 and OS X 10.8 do not.

Compliant Solution (POSIX, Entropy)

The previous noncompliant code example can be solved by using a more reliable source for random number generation. This compliant solution uses the CPU clock in addition to the real-time clock to seed the random number generator:

#include <time.h>
#include <unistd.h>
#include <stdlib.h>

void func(void) {     
  double cpu_time;
  struct timeval tv;
  unsigned long junk;

  cpu_time = ((double) clock()) / CLOCKS_PER_SEC;
  gettimeofday(&tv, NULL);
  srandom((getpid() << 16) ^ tv.tv_sec ^ tv.tv_usec ^ junk);
}

Exceptions

EXP33-EX1: Reading uninitialized memory of type unsigned char does not trigger undefined behavior. The unsigned char type is defined to not have a trap representation (see the C Standard, subclause 6.2.6.1, paragraph 3), which allows for moving bytes without knowing if they are initialized. However, on some architectures, such as the Intel Itanium, registers have a bit to indicate whether or not they have been initialized. The C Standard, subclause 6.3.2.1, paragraph 2, allows such implementations to cause a trap for an object that never had its address taken and is stored in a register if such an object is referred to in any way.

Risk Assessment

Accessing uninitialized variables is undefined behavior and can result in unexpected program behavior.  In some cases, these security flaws may allow the execution of arbitrary code.

Using uninitialized variables for creating entropy is problematic, because these memory accesses can be removed by compiler optimization. VU#925211 is an example of a vulnerability caused by this coding error.

Automated Detection

Related Vulnerabilities

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

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

Related Guidelines

Bibliography