CWE-457¶

Use of Uninitialized Variable. [Improper-Control-Of-A-Resource-Through-Its-Lifetime]

Required inputs: IR

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.

Demonstrative Examples

Example 1

This code prints a greeting using information stored in a POST request:

Example Language:PHP (Unsupported language for documentation only)
    if (isset($_POST['names'])) {
        $nameArray = $_POST['names'];
    }
    echo "Hello " . $nameArray['first'];

This code checks if the POST array 'names' is set before assigning it to the $nameArray variable. However, if the array is not in the POST request, $nameArray will remain uninitialized. This will cause an error when the array is accessed to print the greeting message, which could lead to further exploit.

Example 2

The following switch statement is intended to set the values of the variables aN and bN before they are used:

Example Language:C
    int aN, Bn;
    switch (ctl) {
        case -1:
            aN = 0;
            bN = 0;
            break;

        case 0:
            aN = i;
            bN = -i;
            break;

        case 1:
            aN = i + NEXT_SZ;
            bN = i - NEXT_SZ;
            break;

        default:
            aN = -1;
            aN = -1;
            break;
    }
    repaint(aN, bN);

In the default case of the switch statement, the programmer has accidentally set the value of aN twice. As a result, bN will have an undefined value. Most uninitialized variable issues result in general software reliability problems, but if attackers can intentionally trigger the use of an uninitialized variable, they might be able to launch a denial of service attack by crashing the program. Under the right circumstances, an attacker may be able to control the value of an uninitialized variable by affecting the values on the stack prior to the invocation of the function.

Example 3

This example will leave test_string in an unknown condition when i is the same value as err_val, because test_string is not initialized (CWE-456). Depending on where this code segment appears (e.g. within a function body), test_string might be random if it is stored on the heap or stack. If the variable is declared in static memory, it might be zero or NULL. Compiler optimization might contribute to the unpredictability of this address.

Example Language:Cchar *test_string;
    if (i != err_val)
    {

        test_string = "Hello World!";
    }
    printf("%s", test_string);

When the printf() is reached, test_string might be an unexpected address, so the printf might print junk strings (CWE-457).

To fix this code, there are a couple approaches to making sure that test_string has been properly set once it reaches the printf().

One solution would be to set test_string to an acceptable default before the conditional:

Example Language:Cchar *test_string = "Done at the beginning";
    if (i != err_val)
    {

        test_string = "Hello World!";
    }
    printf("%s", test_string);

Another solution is to ensure that each branch of the conditional - including the default/else branch - could ensure that test_string is set:

Example Language:Cchar *test_string;
    if (i != err_val)
    {

        test_string = "Hello World!";
    }
    else {

        test_string = "Done on the other side!";
    }
    printf("%s", test_string);

Possible Messages

Key	Text	Severity	Disabled
assigned_to_pointer_to_const	Assigning the address of a partially initialized variable to some pointer-to-const	None	False
pass_as_pointer_to_const_param	Passing uninitialized variable by pointer as function parameter with pointer-to-const type	None	False
possible_return_value_uninit	Function return value is potentially not initialized	None	False
possible_uninit	Use of possibly uninitialized variable	None	False
possibly_initialized	Use of possibly uninitialized variable (previous call {node0} might have initialized the variable)	None	False
return_value_uninit	Function return value is not initialized	None	False
uninit	Use of uninitialized variable	None	False

Options¶

This rule shares the following common options: exclude_in_macros, exclude_messages_in_system_headers, excludes, extend_exclude_to_macro_invocations, includes, justification_checker, languages, post_processing, provider, report_at, severity
The following places define options that affect this rule: Stylechecks, Analysis-GlobalOptions

additional_local_array_check¶

additional_local_array_check : bool = True

Invoke an additional analysis that tries to remove false positives involving accesses to local array variables and in particular their initialization. The analysis attempts to report only the first use of an uninitialized value. Consider e.g. the following example:

    int example()
    {
        int a[10];
        int b[20];
        int uninit_var;
        for (int i = 0; i < 10; ++i)
        {
L1:         a[i] = uninit_var; // use of uninit_var reported
            b[i] = i;
        }
        int result = a[3]; // not reported, since already reported at L1
        result += b[15]; // reported; c[] is not (completely) initialized
        return result;
    }

assume_globals_are_initialized¶

assume_globals_are_initialized : bool = True

Whether global and local static variables should be treated as initialized (as specified by the language).

check_array_access_with_unknown_index¶

check_array_access_with_unknown_index : bool = False

Whether array accesses like a[i] with non-literal index i should be checked as well.

exclude_from_pointer_to_const_param_check¶

exclude_from_pointer_to_const_param_check : set[bauhaus.analysis.config.QualifiedName] = {'__builtin_object_size'}

Names of routines whose parameters should be excluded from the check for passing uninitialized variables by pointer as parameter with pointer-to-const type.

track_conditional_initialization¶

track_conditional_initialization : bool = True

Whether higher precision should be used to eliminate cases where the initialization and the access are controlled by conditions in a way that the variable access is only executed when the initialization was executed. Requires more memory and runtime but can eliminate some false positives.

use_semantic_analysis¶

use_semantic_analysis : bool = True

When enabled, use semantic analysis. Otherwise filter uninitialized variable messages from the compiler.

writing_into_pointer_to_const¶

writing_into_pointer_to_const

Type: dict[bauhaus.analysis.config.QualifiedName, int]

Default:
{
   'cudaMemcpyToSymbol': 0
}

Names of routines (mapping to parameter index, starting at 0) having a parameter declared as pointer-to-const yet they are still writing into the pointee.

Axivion Suite 7.12.0

Navigation