Use of Uninitialized Variable |
Weakness ID: 457 (Weakness Variant) | Status: Draft |
Description Summary
Extended Description
In some languages, such as C, an uninitialized variable contains contents of previously-used memory. An attacker can sometimes control or read these contents.
Scope | Effect |
---|---|
Availability Integrity | 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 | 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. |
Example 1
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. 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.
Example 2
Reference | Description |
---|---|
CVE-2008-0081 | Uninitialized variable leads to code execution in popular desktop application. |
CVE-2007-4682 | Crafted input triggers dereference of an uninitialized object pointer. |
CVE-2007-3468 | Crafted audio file triggers crash when an uninitialized variable is used. |
CVE-2007-2728 | Uninitialized random seed variable used. |
Phase: Implementation Assign all variables to an initial value. |
Phase: Build and Compilation Most compilers will complain about the use of uninitialized variables if warnings are turned on. |
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. |
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. 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. 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. |
Nature | Type | ID | Name | View(s) this relationship pertains to![]() |
---|---|---|---|---|
ChildOf | ![]() | 398 | Indicator of Poor Code Quality | Seven Pernicious Kingdoms (primary)700 |
ChildOf | ![]() | 456 | Missing Initialization | Development Concepts (primary)699 Research Concepts (primary)1000 |
MemberOf | ![]() | 630 | Weaknesses Examined by SAMATE | Weaknesses Examined by SAMATE (primary)630 |
Mapped Taxonomy Name | Node ID | Fit | Mapped Node Name |
---|---|---|---|
CLASP | Uninitialized variable | ||
7 Pernicious Kingdoms | Uninitialized Variable |
A weakness where the code path has: 1. start statement that defines variable 2. end statement that accesses the variable 3. the code path does not contain a statement that assigns value to the variable |
mercy. "Exploiting Uninitialized Data". Jan 2006. < http://www.felinemenace.org/~mercy/papers/UBehavior/UBehavior.zip>. |
Microsoft Security Vulnerability Research & Defense. "MS08-014 : The Case of the Uninitialized Stack Variable Vulnerability". 2008-03-11. <http://blogs.technet.com/swi/archive/2008/03/11/the-case-of-the-uninitialized-stack-variable-vulnerability.aspx>. |
Submissions | ||||
---|---|---|---|---|
Submission Date | Submitter | Organization | Source | |
CLASP | Externally Mined | |||
Modifications | ||||
Modification Date | Modifier | Organization | Source | |
2008-07-01 | Eric Dalci | Cigital | External | |
updated Time of Introduction | ||||
2008-08-01 | KDM Analytics | External | ||
added/updated white box definitions | ||||
2008-09-08 | CWE Content Team | MITRE | Internal | |
updated Applicable Platforms, Common Consequences, Description, Relationships, Observed Example, Other Notes, References, Taxonomy Mappings | ||||
2009-01-12 | CWE Content Team | MITRE | Internal | |
updated Common Consequences, Demonstrative Examples, Potential Mitigations | ||||
2009-03-10 | CWE Content Team | MITRE | Internal | |
updated Demonstrative Examples | ||||
2009-05-27 | CWE Content Team | MITRE | Internal | |
updated Demonstrative Examples | ||||
Previous Entry Names | ||||
Change Date | Previous Entry Name | |||
2008-04-11 | Uninitialized Variable | |||