The code uses a variable that has not been initialized, leading to unpredictable or unintended results.
Extended Description
In some languages such as C and C++, stack variables are not initialized by default. They generally contain junk data with the contents of stack memory before the function was invoked. An attacker can sometimes control or read these contents. In other languages or conditions, a variable that is not explicitly initialized can be given a default value that has security implications, depending on the logic of the program. The presence of an uninitialized variable can sometimes indicate a typographic error in the code.
Time of Introduction
Implementation
Applicable Platforms
Languages
C: (Sometimes)
C++: (Sometimes)
Perl: (Often)
PHP: (Often)
Language-independent
Common Consequences
Scope
Effect
Availability
Integrity
Other
Technical Impact: Other
Initial variables usually contain junk, which can not be trusted for
consistency. This can lead to denial of service conditions, or modify
control flow in unexpected ways. In some cases, an attacker can
"pre-initialize" the variable using previous actions, which might enable
code execution. This can cause a race condition if a lock variable check
passes when it should not.
Authorization
Other
Technical Impact: Other
Strings that are not initialized are especially dangerous, since many
functions expect a null at the end -- and only at the end -- of a
string.
Likelihood of Exploit
High
Demonstrative Examples
Example 1
This code prints a greeting using information stored in a POST
request:
(Bad Code)
Example
Language: PHP
if (isset($_POST['names'])) {
$nameArray = $_POST['names'];
}
echo "Hello " . $nameArray['first'];
This code checks if the POST array 'names' is set before assigning it
to the $nameArray variable. However, if the array is not in the POST
request, $nameArray will remain uninitialized. This will cause an error
when the array is accessed to print the greeting message, which could
lead to further exploit.
Example 2
The following switch statement is intended to set the values of the
variables aN and bN before they are used:
(Bad Code)
Example
Language: C
int aN, Bn;
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);
In the default case of the switch statement, the programmer has
accidentally set the value of aN twice. As a result, bN will have an
undefined value. 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.
Most compilers will complain about the use of uninitialized variables
if warnings are turned on.
Phases: Implementation; Operation
When using a language that does not require explicit declaration of
variables, run or compile the software in a mode that reports undeclared
or unknown variables. This may indicate the presence of a typographic
error in the variable's name.
Phase: Requirements
The choice could be made to use a language that is not susceptible to
these issues.
Phase: Architecture and Design
Mitigating technologies such as safe string libraries and container
abstractions could be introduced.
Other Notes
If one forgets -- in the C language -- to initialize, for example a char
*, many of the simple string libraries may often return incorrect results as
they expect the null termination to be at the end of a string.
[REF-17] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.
[REF-7] Mark Dowd, John McDonald
and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Variable Initialization", Page
312.. 1st Edition. Addison Wesley. 2006.