CWE-665 is the weakness of not initializing a resource, or initializing it incorrectly, so it is in an unexpected state when used. It becomes a security problem when the resource is expected to hold particular values, like a flag that says whether a user has been authenticated. It affects every language, though C and C++ expose it most directly.
How it happens
There are a few common routes.
Reading memory that was never set. In C, a local variable or a heap block has whatever bytes were there before. Using it can leak old data or steer program flow.
Relying on a default you did not choose. Some languages set defaults for you. MITRE notes that if a security decision depends on a variable being zero or equivalent, and the language sets that on the programmer's behalf, a bypass can result when the default is not what the author assumed.
Skipping initialization on one path. A complex conditional may set a variable on most paths but not all.
Racing during startup. Initialization routines can be hit by race conditions (CWE-362).
/* Vulnerable: 'authenticated' is only set on one path */
int authenticated; /* uninitialized */
if (check_password(user, pw))
authenticated = 1;
if (authenticated) grant_access(); /* garbage value may be nonzero */
If the password check fails, authenticated holds whatever happened to be on the stack. On many systems that is nonzero often enough to matter.
The record lists four examples:
- CVE-2001-1471: a chain where an invalid value prevents a library file from being included, skipping initialization of key variables, leading to resultant eval injection.
- CVE-2008-3637: improper error checking in a protection mechanism produces an uninitialized variable, allowing security bypass and code execution.
- CVE-2008-4197: use of uninitialized memory may allow code execution.
- CVE-2008-2934: free of an uninitialized pointer leads to a crash and possible code execution.
Notice the first two are chains. A failed error check or an unusual input skips the code that sets things up, and the gap turns into something worse.
What an attacker gains
MITRE lists three consequences.
- Confidentiality. When a resource such as memory or a variable is reused, its old contents may not be cleared before it is sent to an untrusted party. The attacker reads memory or application data.
- Access control. If a security decision relies on a variable being zero or equivalent, and initialization is not what the author expected, protection can be bypassed.
- Availability. Uninitialized data can change program flow in unintended ways. For example, an uninitialized variable used as an array index in C may point outside the array and crash the program.
How to find it
The record lists three detection approaches.
- Automated dynamic analysis. Use fuzzing, stress testing and fault injection with large test suites and diverse inputs. The software may slow down, but it should not enter an unexpected state.
- Manual dynamic analysis. Trigger error conditions that are unlikely in normal use: low memory, insufficient permissions, an interrupted transaction, lost connectivity.
- Automated static analysis (SAST). It can find some instances by analyzing source or compiled code without executing it.
Compiler warnings are an easy first step. Turn on the warnings for uninitialized variables and treat them as errors in CI. Memory checking tools used during test runs catch reads of uninitialized memory that static tools miss.
How to fix it
MITRE's mitigations, in plain steps:
- Choose a language that helps. Some languages refuse to compile or set safe defaults. For example, in Java an unset local variable is a compile-time error, while a field gets the default for its type. In Perl an unset variable is undef, interpreted as 0, false or an equivalent depending on use. Know what your language does and do not depend on it silently.
- Validate external inputs. Identify all variables and data stores that receive information from external sources and make sure they can only be initialized to expected values.
- Initialize explicitly. Set every variable and data store at declaration or just before first use.
- Check complex conditionals. Pay close attention to branches that might not perform initialization.
- Avoid races during initialization routines.
- Build with warnings on. Compile with settings that generate warnings about uninitialized variables or data.
/* Safer: initialize at declaration, deny by default */
int authenticated = 0;
if (check_password(user, pw))
authenticated = 1;
if (authenticated) grant_access();
Defaulting security flags to the denying value means a skipped branch fails closed.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Why is an uninitialized authentication flag dangerous?
Its value is whatever was in memory before. A nonzero leftover reads as true, so the check can pass without a valid login.
Which two tests does MITRE suggest to find this at runtime?
Fuzzing and fault injection with many diverse inputs, and manually triggering rare error conditions such as low memory or interrupted transactions.
Does a safe default in the language remove the risk?
Not entirely. If your security decision assumes a particular default and the real value differs, protection can still be bypassed. Initialize explicitly.
