CWE-457: Use of Uninitialized VariableWeakness ID: 457 Vulnerability Mapping:
ALLOWEDThis CWE ID may be used to map to real-world vulnerabilities Abstraction: VariantVariant - 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. |
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 This table 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 |
This table 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 "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 |
This table 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 "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. |
Common Consequences This table 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
| 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
| 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 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 |
| Chain: sscanf() call is used to check if a username and group exists, but the return value of sscanf() call is not checked ( CWE-252), causing an uninitialized variable to be checked ( CWE-457), returning success to allow authorization bypass for executing a privileged ( CWE-863). |
| 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. |
| Uninitialized variable leads to code execution in popular desktop application. |
| Crafted input triggers dereference of an uninitialized object pointer. |
| Crafted audio file triggers crash when an uninitialized variable is used. |
| 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. |
Detection Methods
Fuzzing Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues. |
Automated Static Analysis Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) |
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. Vulnerability Mapping Notes Usage: ALLOWED (this CWE ID could be used to map to real-world vulnerabilities) | Reason: Acceptable-Use | Rationale: This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities. | Comments: Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction. |
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-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 (CWE Draft 3, 2006-07-19) | CLASP | | | Modifications |
---|
Modification Date | Modifier | Organization |
---|
2008-07-01 | Eric Dalci | Cigital | updated Time_of_Introduction | 2008-08-01 | | KDM Analytics | added/updated white box definitions | 2008-09-08 | CWE Content Team | MITRE | updated Applicable_Platforms, Common_Consequences, Description, Relationships, Observed_Example, Other_Notes, References, Taxonomy_Mappings | 2009-01-12 | CWE Content Team | MITRE | updated Common_Consequences, Demonstrative_Examples, Potential_Mitigations | 2009-03-10 | CWE Content Team | MITRE | updated Demonstrative_Examples | 2009-05-27 | CWE Content Team | MITRE | updated Demonstrative_Examples | 2011-06-01 | CWE Content Team | MITRE | updated Common_Consequences | 2012-05-11 | CWE Content Team | MITRE | updated References, Relationships | 2012-10-30 | CWE Content Team | MITRE | updated Demonstrative_Examples | 2013-02-21 | CWE Content Team | MITRE | updated Applicable_Platforms, Description, Other_Notes, Potential_Mitigations, Relationships | 2014-06-23 | CWE Content Team | MITRE | updated Modes_of_Introduction, Other_Notes | 2014-07-30 | CWE Content Team | MITRE | updated Relationships, Taxonomy_Mappings | 2017-11-08 | CWE Content Team | MITRE | updated References, Relationships, Taxonomy_Mappings, White_Box_Definitions | 2019-01-03 | CWE Content Team | MITRE | updated Taxonomy_Mappings | 2019-06-20 | CWE Content Team | MITRE | updated Relationships, Type | 2020-02-24 | CWE Content Team | MITRE | updated References, Relationships, Type | 2020-08-20 | CWE Content Team | MITRE | updated Relationships | 2020-12-10 | CWE Content Team | MITRE | updated Relationships | 2021-03-15 | CWE Content Team | MITRE | updated Demonstrative_Examples, Observed_Examples, Relationships | 2021-07-20 | CWE Content Team | MITRE | updated Observed_Examples | 2023-04-27 | CWE Content Team | MITRE | updated Detection_Factors, References, Relationships | 2023-06-29 | CWE Content Team | MITRE | updated Mapping_Notes | Previous Entry Names |
---|
Change Date | Previous Entry Name |
---|
2008-04-11 | Uninitialized Variable | |
More information is available — Please edit the custom filter or select a different filter.
|