CWE - CWE-457: Use of Uninitialized Variable (4.4)

Weakness ID: 457

Abstraction: Variant
Structure: Simple

Status: Draft

Presentation Filter:

Description

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.

Relationships

The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (CWE-1000)

Nature	Type	ID	Name
ChildOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	908	Use of Uninitialized Resource
CanFollow	Variant - a weakness that is linked to a certain type of product, typically involving a specific language or technology. More specific than a Base weakness. Variant level weaknesses typically describe issues in terms of 3 to 5 of the following dimensions: behavior, property, technology, language, and resource.	456	Missing Initialization of a Variable

Relevant to the view "CISQ Quality Measures (2020)" (CWE-1305)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	665	Improper Initialization

Relevant to the view "CISQ Data Protection Measures" (CWE-1340)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	665	Improper Initialization

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Phase	Note
Implementation	In C, using an uninitialized char * in some string libraries will return incorrect results, as the libraries expect the null terminator to always be at the end of a string, even if the string is empty.

Applicable Platforms

The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Languages

C (Sometimes Prevalent)

C++ (Sometimes Prevalent)

Perl (Often Prevalent)

PHP (Often Prevalent)

Class: Language-Independent (Undetermined Prevalence)

Common Consequences

The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Scope	Impact	Likelihood
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.

Example 3

This example will leave test_string in an unknown condition when i is the same value as err_val, because test_string is not initialized (CWE-456). Depending on where this code segment appears (e.g. within a function body), test_string might be random if it is stored on the heap or stack. If the variable is declared in static memory, it might be zero or NULL. Compiler optimization might contribute to the unpredictability of this address.

(bad code)

Example Language: C

char *test_string;
if (i != err_val)
{

test_string = "Hello World!";

}
printf("%s", test_string);

When the printf() is reached, test_string might be an unexpected address, so the printf might print junk strings (CWE-457).

To fix this code, there are a couple approaches to making sure that test_string has been properly set once it reaches the printf().

One solution would be to set test_string to an acceptable default before the conditional:

(good code)

Example Language: C

char *test_string = "Done at the beginning";
if (i != err_val)
{

test_string = "Hello World!";

}
printf("%s", test_string);

Another solution is to ensure that each branch of the conditional - including the default/else branch - could ensure that test_string is set:

(good code)

Example Language: C

char *test_string;
if (i != err_val)
{

test_string = "Hello World!";

}
else {

test_string = "Done on the other side!";

}
printf("%s", test_string);

Observed Examples

Reference	Description
CVE-2008-3688	Chain: A denial of service may be caused by an uninitialized variable (CWE-457) allowing an infinite loop (CWE-835) resulting from a connection to an unresponsive server.
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.

Potential Mitigations

Phase: Implementation

Strategy: Attack Surface Reduction

Assign all variables to an initial value.

Phase: Build and Compilation

Strategy: Compilation or Build Hardening

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.

Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	398	7PK - Code Quality
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	998	SFP Secondary Cluster: Glitch in Computation
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1180	SEI CERT Perl Coding Standard - Guidelines 02. Declarations and Initialization (DCL)

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
CLASP			Uninitialized variable
7 Pernicious Kingdoms			Uninitialized Variable
Software Fault Patterns	SFP1		Glitch in computation
SEI CERT Perl Coding Standard	DCL33-PL	Imprecise	Declare identifiers before using them

References

[REF-18] Secure Software, Inc.. "The CLASP Application Security Process". 2005. <https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf>.

[REF-436] mercy. "Exploiting Uninitialized Data". 2006-01. <http://www.felinemenace.org/~mercy/papers/UBehavior/UBehavior.zip>.

[REF-437] 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>.

[REF-44] Michael Howard, David LeBlanc and John Viega. "24 Deadly Sins of Software Security". "Sin 8: C++ Catastrophes." Page 143. McGraw-Hill. 2010.

[REF-62] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Variable Initialization", Page 312. 1st Edition. Addison Wesley. 2006.

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19	CLASP
2006-07-19
Modifications
Modification Date	Modifier	Organization
2008-07-01	Eric Dalci	Cigital
2008-07-01	updated Time_of_Introduction
2008-08-01		KDM Analytics
2008-08-01	added/updated white box definitions
2008-09-08	CWE Content Team	MITRE
2008-09-08	updated Applicable_Platforms, Common_Consequences, Description, Relationships, Observed_Example, Other_Notes, References, Taxonomy_Mappings
2009-01-12	CWE Content Team	MITRE
2009-01-12	updated Common_Consequences, Demonstrative_Examples, Potential_Mitigations
2009-03-10	CWE Content Team	MITRE
2009-03-10	updated Demonstrative_Examples
2009-05-27	CWE Content Team	MITRE
2009-05-27	updated Demonstrative_Examples
2011-06-01	CWE Content Team	MITRE
2011-06-01	updated Common_Consequences
2012-05-11	CWE Content Team	MITRE
2012-05-11	updated References, Relationships
2012-10-30	CWE Content Team	MITRE
2012-10-30	updated Demonstrative_Examples
2013-02-21	CWE Content Team	MITRE
2013-02-21	updated Applicable_Platforms, Description, Other_Notes, Potential_Mitigations, Relationships
2014-06-23	CWE Content Team	MITRE
2014-06-23	updated Modes_of_Introduction, Other_Notes
2014-07-30	CWE Content Team	MITRE
2014-07-30	updated Relationships, Taxonomy_Mappings
2017-11-08	CWE Content Team	MITRE
2017-11-08	updated References, Relationships, Taxonomy_Mappings, White_Box_Definitions
2019-01-03	CWE Content Team	MITRE
2019-01-03	updated Taxonomy_Mappings
2019-06-20	CWE Content Team	MITRE
2019-06-20	updated Relationships, Type
2020-02-24	CWE Content Team	MITRE
2020-02-24	updated References, Relationships, Type
2020-08-20	CWE Content Team	MITRE
2020-08-20	updated Relationships
2020-12-10	CWE Content Team	MITRE
2020-12-10	updated Relationships
2021-03-15	CWE Content Team	MITRE
2021-03-15	updated Demonstrative_Examples, Observed_Examples, Relationships
Previous Entry Names
Change Date	Previous Entry Name
2008-04-11	Uninitialized Variable


	Site Map \| Terms of Use \| Privacy Policy \| Contact Us \| Use of the Common Weakness Enumeration (CWE) and the associated references from this website are subject to the Terms of Use. CWE is sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA) and managed by the Homeland Security Systems Engineering and Development Institute (HSSEDI) which is operated by The MITRE Corporation (MITRE). Copyright © 2006-2021, The MITRE Corporation. CWE, CWSS, CWRAF, and the CWE logo are trademarks of The MITRE Corporation.

Common Weakness Enumeration

CWE-457: Use of Uninitialized Variable