Weakness · High
CWE-457: Use of Uninitialized Variable
What it is
The code uses a variable that has not been initialized, leading to unpredictable or unintended results.
- Severity (our rating)
- High
- Likelihood of exploit
- High
- Introduced during
- Implementation
- Exploited in the wild
- No CVE in CISA's catalog
In more detail
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.
What an attacker can do
- Other (Availability, Integrity, Other, Authorization)
How to prevent it
Implementation
- Ensure that critical variables are initialized before first use.
- 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.
Build and Compilation
- Most compilers will complain about the use of uninitialized variables if warnings are turned on.
Requirements
- Choose a language that is not susceptible to these issues.
Architecture and Design
- Mitigating technologies such as safe string libraries and container abstractions could be introduced.
How to find it
- 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.)
H2 Security
Found it in your code?
We review where it appears, fix it with your team, and check it was not already used against you.
Talk to our teamT Academy
Stop writing it in the first place
Learn to build software and systems without weaknesses like this one, with practice on real hosts in your browser, every objective checked on the machine.
Start freeSource: MITRE Common Weakness Enumeration, CWE version 4.19.1. CWE is a trademark of The MITRE Corporation.