CWE-456, Missing Initialization of a Variable, is the design-time flaw behind many crashes and some exploits. The product does not initialize critical variables, so the execution environment uses unexpected values.
It is closely related to CWE-457, Use of Uninitialized Variable, which is the moment the bad value is actually read. CWE-456 is the omission. CWE-457 is the consequence. Both mostly bite C and C++ code, though the MITRE entry also includes a Java example.
How it happens
The usual pattern is a path through the code that skips the assignment. MITRE's C example extracts two numbers from user input:
void parse_data(char *untrusted_input) {
int m, n, error;
error = sscanf(untrusted_input, "%d:%d", &m, &n);
if (EOF == error) {
die("Did not specify integer value. Die evil hacker!\n");
}
/* proceed assuming n and m are initialized correctly */
}
If an attacker sends the input 123: then only m is set. The code proceeds as though n is valid and uses whatever value happened to be in memory. The check tests for EOF, but sscanf can return a count lower than two without reaching EOF.
The Java example in the entry has an uninitialized field used in a seldom-called method, which throws a NullPointerException when that method finally runs.
MITRE's observed CVEs are all chains, where the missing initialization is one link:
- CVE-2020-6078: a function's pointer return value is not checked for success, so a later use of an uninitialized variable leads to a null pointer dereference.
- CVE-2019-3836: a secure communications library did not initialize a local variable for a data structure, leading to access of an uninitialized pointer.
- CVE-2018-14641: a C union member was not initialized, leading to access of an invalid pointer.
- CVE-2009-2692: use of an unimplemented network socket operation pointed to an uninitialized handler function, causing a crash through a null pointer dereference.
What an attacker gains
MITRE lists integrity impact, an unexpected state and quality degradation. The uninitialized data may be invalid, causing logic errors. In some cases this becomes a security problem, and the chained CVEs above show crashes and invalid pointer access.
How to find it
MITRE notes that automated static analysis can find some instances by modeling data flow. Practical checks:
- Turn on compiler warnings. Most compilers complain about the use of uninitialized variables when warnings are enabled.
- Check the return value of every call that fills a variable, and confirm the whole expected set was filled.
- Test with malformed and partial input, like the trailing colon above.
How to fix it
From the record:
- Ensure critical variables are initialized before first use.
- Choose a language that is not susceptible to these issues, where you can.
A repaired version of the parser initializes everything and checks the count:
void parse_data(char *untrusted_input) {
int m = 0, n = 0;
int matched = sscanf(untrusted_input, "%d:%d", &m, &n);
if (matched != 2) {
die("Bad input\n");
}
/* m and n are both valid here */
}
Zero values plus a strict match count make the failure explicit and keep stale memory out of the logic.
Quick check
How does CWE-456 differ from CWE-457?
CWE-456 is failing to initialize a critical variable. CWE-457 is using a variable that was never initialized. The first is the omission, the second is the use.
Why is checking only for EOF not enough in the sscanf example?
sscanf can return fewer matches than expected without hitting EOF. Compare the returned count with the number of values you need.
