Page History

Local, automatic variables can assume unexpected values if they are used before they are initialized. C99 specifies, "If an object that has automatic storage duration is not initialized explicitly, its value is [indeterminate| BB. Definitions#indeterminate value]" \[[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999]\]. (See also [undefined behavior 10 | CC. Undefined Behavior#ub_10] of Annex J.) 

In the common case, on [implementations| BB. Definitions#implementation] that make use of a program stack, this value defaults to whichever values are currently stored in stack memory. While uninitialized memory often contains zeroes, this is not guaranteed. On implementations that include [trap representations|BB. Definitions#trap representation], reading an uninitialized object of any type other than {{unsigned char}} (i.e., including {{int}}) may trigger a trap. (See [undefined behavior 11 | CC. Undefined Behavior#ub_11] of Annex J.) Consequently, uninitialized memory can cause a program to behave in an unpredictable or unplanned manner, lead to [undefined behavior | BB. Definitions#undefined behavior], and may can provide an avenue for attack.

Additionally, memory allocated by functions, such as malloc(), should not be used before being initialized as its contents are indeterminate.

In most cases, compilers warn about uninitialized variables. These warnings should be resolved as recommended by guidline , discussed in recommendation MSC00-C. Compile cleanly at high warning levels.

...

In this noncompliant code example, the set_flag() function is intended to set the variable sign to -1 when number is negative and or 1 otherwise. However, the programmer neglected to account for number being 0. If number is 0, then sign remains uninitialized. Because sign is uninitialized, and again assuming that the architecture makes use of a program stack, it uses whatever value is at that location in the program stack. This may lead to unexpected or otherwise incorrect program behavior.

...

This defect results from a failure to consider all possible data states. (See guideline recommendation MSC01-C. Strive for logical completeness.) Once the problem is identified, it can be trivially repaired by accounting for the possibility that number can be equal to 0.

...

In this noncompliant code example, the programmer mistakenly fails to set the local variable {{error_log}} to the {{msg}} argument in the {{report_error()}} function \[[Mercy 2006|AA. Bibliography#mercy 06]\].  Because {{error_log}} has not been initialized, on architectures making use of a program stack, it assumes the value already on the stack at this location, which is a pointer to the stack memory allocated to the {{password}} array.  The {{sprintf()}} call copies data in {{password}} until a null byte is reached. If the length of the string stored in the {{password}} array is greater than the size of the {{buffer}} array, then a buffer overflow occurs.

...

This solution is still problematic because a buffer overflow will occur if the null-terminated byte string referenced by msg is greater than 17 bytes, including the NULL terminator. The solution also makes use of a "magic number," which should be avoided. (See guideline recommendation DCL06-C. Use meaningful symbolic constants to represent literal values in program logic.)

Compliant Solution

In this solution, the magic number is abstracted, and the buffer overflow is eliminated.

...

Accessing uninitialized variables generally leads to unexpected program behavior. In some cases, these types of flaws may allow the execution of arbitrary code.

Distributions derived from Debian, particularly VU#925211 in the OpenSSL package for Debian Linux, and other distributions derived from Debian, is are said to reference uninitialized memory. One might say that uninitialized memory caused causes the vulnerability, but this is not directlyentirely true. The original OpenSSL code used uses uninitialized memory as an additional source of randomness to an already-randomly-generated key. This generated generates good keys, but caused also causes the code-auditing tools Valgrind and Purify to issue warnings. Debian tried tries to fix the warnings with two changes. One actually eliminated eliminates the uninitialized memory access, but the other weakened weakens the randomness of the keys.

...

Searchfor vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

CERT C++ Secure Coding Standard: EXP33-CPP. Do not reference uninitialized memory.

Bibliography

unmigrated-wiki-markup

\[[Flake 2006|AA. Bibliography#Flake 06]\] \[[ISO/IEC 9899:1999|AA. Bibliography#ISO/IEC 9899-1999]\] Section 6.7.8, "Initialization"

ISO/IEC TR 24772 "LAV Initialization of Variables"

Bibliography

\[[ISO/IEC PDTR 24772Flake 2006|AA. Bibliography#ISO/IEC PDTR 24772Bibliography#Flake 06]\] "LAV Initialization of Variables"
\[[Mercy 2006|AA. Bibliography#mercy 06]\]
\[[xorl 2009|AA. Bibliography#xorl 2009]\] ["CVE-2009-1888: SAMBA ACLs Uninitialized Memory Read"|http://xorl.wordpress.com/2009/06/26/cve-2009-1888-samba-acls-uninitialized-memory-read/]

...