Uninitialized Variable

Last revision (mm/dd/yy): //

Vulnerabilities Table of Contents

Description
Using the value of an unitialized variable is not safe.

Consequences


 * Integrity: Initial variables usually contain junk, which can not be trusted for consistency. This can cause a race condition if a lock variable check passes when it should not.
 * Authorization: Strings which are not initialized are especially dangerous, since many functions expect a null at the end - and only at the end - of a string.

Exposure period


 * Implementation: Use of unitialized variables is a logical bug.
 * Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
 * Design: Mitigating technologies such as safe string libraries and container abstractions could be introduced.

Platform

Languages: C/C++

Operating platforms: Any

Required resources

Any

Severity

High

Likelihood of exploit

High

Before variables are initialized, they generally contain junk data of what was left in the memory that the variable takes up. This data is very rarely useful, and it is generally advised to pre-initialize variables or set them to their first values early.

In C, if one forgets to initialize, for example a char *, many of the simple string libraries may often return incorrect results as they expecting the null termination to be at the end of a string.

The program can potentially use a variable before it has been initialized.

Stack variables in C and C++ are not initialized by default. Their initial values are determined by whatever happens to be in their location on the stack at the time the function is invoked. Programs should never use the value of an uninitialized variable.

It is not uncommon for programmers to use an uninitialized variable in code that handles errors or other rare and exceptional circumstances. Uninitialized variable warnings can sometimes indicate the presence of a typographic error in the code.

Risk Factors
TBD

Example 1
In C\C++, or Java:

int foo; void bar{ if (foo==0) /.../ /../ }

Example 2
The following switch statement is intended to set the values of the variables aN and bN, but in the default case, the programmer has accidentally set the value of aN twice.

switch (ctl) { case -1: aN = 0; bN = 0; break; case 0: aN = i; bN = -i; break; case 1: aN = i + NEXT_SZ; bN = i - NEXT_SZ; break; default: aN = -1; aN = -1; break; }	repaint(aN, bN);

Most uninitialized variable issues result in general software reliability problems, but if attackers can intentionally trigger the use of an uninitialized variable, they might be able to launch a denial of service attack by crashing the program. Under the right circumstances, an attacker may be able to control the value of an uninitialized variable by affecting the values on the stack prior to the invocation of the function.

Related Attacks

 * Attack 1
 * Attack 2

Related Vulnerabilities

 * Vulnerability 1
 * Vulnerabiltiy 2

Related Controls

 * Implementation: Assign all variables to an initial variable.
 * Pre-design through Build: Most compilers will complain about the use of unitialized variables if warnings are turned on.
 * Requirements specification: The choice could be made to use a language that is not susceptible to these issues.
 * Design: Mitigating technologies such as safe string libraries and container abstractions could be introduced.

Related Technical Impacts

 * Technical Impact 1
 * Technical Impact 2