Use of Uninitialized Variable

Opis

The code uses a variable that has not been initialized, leading to unpredictable or unintended results.

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.

Skutki

• Availability, Integrity, Other

  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

  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.

Zapobieganie

• Implementation · Attack Surface Reduction

  Ensure that critical variables are initialized before first use [REF-1485].

• Build and Compilation · Compilation or Build Hardening

  Most compilers will complain about the use of uninitialized variables if warnings are turned on.

• 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.

• Requirements · Language Selection

  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.

Przykłady podatności

• CVE-2019-15900 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).
• CVE-2008-3688 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.
• CVE-2008-0081 Uninitialized variable leads to code execution in popular desktop application.
• CVE-2007-4682 Crafted input triggers dereference of an uninitialized object pointer.
• CVE-2007-3468 Crafted audio file triggers crash when an uninitialized variable is used.
• CVE-2007-2728 Uninitialized random seed variable used.

Słabość nadrzędna

• CWE-908 Use of Uninitialized Resource
• CWE-665 Improper Initialization

Kiedy powstaje

• 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.

Dotyczy

C, C++, Perl, PHP, Not Language-Specific

Źródła

1. The CLASP Application Security Process — Secure Software, Inc., 2005
2. Exploiting Uninitialized Data — mercy, 2006
3. MS08-014 : The Case of the Uninitialized Stack Variable Vulnerability — Microsoft Security Vulnerability Research & Defense, 2008
4. 24 Deadly Sins of Software Security — Michael Howard, David LeBlanc, John Viega, "Sin 8: C++ Catastrophes." Page 143, McGraw-Hill, 2010
5. The Art of Software Security Assessment — Mark Dowd, John McDonald, Justin Schuh, Chapter 7, "Variable Initialization", Page 312, Addison Wesley, 2006
6. D3FEND: D3-VI Variable Initialization — D3FEND