Crashing and Non-Crashing Vulnerabilities

CodeSonar distinguishes between vulnerabilities that will crash a program and vulnerabilities that will cause undesirable behavior without (necessarily) crashing the program. The Null Pointer Dereference and Division by Zero warning classes describe crashing vulnerabilities, all others are non-crashing vulnerabilities. Both crashing and non-crashing vulnerabilities have implications for the analysis.

• Crashing Vulnerabilities
• Non-Crashing Vulnerabilities

Crashing Vulnerabilities

Description

A crashing vulnerability on an execution path represents a point beyond which execution can never continue if the vulnerability is triggered, because the program will crash.

Although vulnerabilities of various classes may cause program crashes under certain circumstances, the only classes whose vulnerabilities will always cause a program crash are Null Pointer Dereference and Division by Zero. Therefore, these are the two "crashing vulnerability" classes.

Analysis Behavior

By default, the CodeSonar analysis will treat Null Pointer Dereference and Division By Zero bugs as crashing vulnerabilities, as described here. In addition, the analysis will treat integer division overflow (such as -1/MIN_INT) as a crashing vulnerability (but without issuing a warning). To circumvent this treatment and instruct the analysis to treat these as non-crashing vulnerabilities, use configuration file parameters DIV_BY_ZERO_CRASHES, NULL_POINTER_DEREF_CRASHES, and DIV_OVERFLOW_CRASHES.

When CodeSonar encounters a crashing vulnerability on some execution path, it proceeds as follows.

1. The analysis issues a warning for the crashing vulnerability.
2. Execution can only proceed past the vulnerability location if the crash does not occur: CodeSonar therefore adds the negation of the conditions that trigger the crashing vulnerability to the set of constraints that must hold for execution to continue along the path. For example, if the crashing vulnerability occurs when x<0 then execution can only proceed past the vulnerability if x≥0.
3. If the added requirements lead to a contradiction in the overall set of constraints, CodeSonar will not analyze any further along that particular path.

This has two consequences:

• If a crashing vulnerability is always triggered on every path into a code region, that region is considered to be unreachable and CodeSonar will issue the appropriate Unreachable Code warning.
• Any vulnerability that occurs after the crashing vulnerability on the same execution path will only trigger a warning on that path if it can occur under conditions that are consistent with the updated constraints.

Example

This simple program contains a crashing vulnerability followed by a non-crashing vulnerability.

int main(int argc, char *argv[])
{
   int i;
   int buf[10];
   int *r;
   
   r=NULL;
   buf[0] = r[0];           /* null dereference */
   for (i = 0; i<10; i++)
      buf[i+1] = buf[i] + i;/* buffer overflow when i==9 */
}

CodeSonar produces three warnings:

Null Pointer Dereference (1)

The line:

buf[0] = r[0];

will always cause a null pointer dereference. This is a crashing vulnerability.

Unreachable Conditional (1)

All program points after the null pointer dereference are marked as unreachable, since the null pointer dereference will always occur. The highest-severity statement in the unreachable block is the loop test i<10, so the warning class is "Unreachable Conditional".

The unreachable code is marked in red:

int main(int argc, char *argv[])
{
   int i;
   int buf[10];
   int *r;
   
   r=NULL;
   buf[0] = r[0];          
   for (i = 0; i<10; i++)
      buf[i+1] = buf[i] + i;
}

Unused Value (1)

The initialization:

r = NULL;

is marked as an unused value because r is set to a value that is not used on any non-crashing path.

Note in particular that a Buffer Overrun warning is not produced, because the buffer overrun is preceded by a crashing vulnerability on every path.

CodeSonar thus reflects accurately the impact of the crashing vulnerability on program execution. Once the crashing vulnerability is corrected, further analysis runs will produce warnings for the previously unreachable vulnerabilities (if any).

Non-Crashing Vulnerabilities

Description

The remaining warning classes describe non-crashing vulnerabilities.

Analysis Behavior

When CodeSonar encounters a non-crashing vulnerability along some execution path it triggers a warning. It will then continue analysis along the same path. In some cases where fixing a vulnerability already on the list of warnings would automatically fix an identical vulnerability on the same path, CodeSonar will suppress the warning for the later vulnerability. This reduces redundant effort for bug-fixers working through an analysis report.

Example

Consider the following program:

int main(int argc, char *argv[])
{
    char buf[10];
        char c;
        
    buf[0] = c;
    buf[1] = c;
}

CodeSonar will issue an Uninitialized Variable warning at the line

However, it will not issue such a warning at the following line, even though c is still not initialized.

A useful way to think about it is this: suppose you were to fix this bug by initializing c. No matter where you put the initialization in the program (so long as you didn't add any additional flow-control commands), if you fixed the first uninitialized variable bug, you would also fix the second.

In contrast, consider the code:

int main(int argc, char *argv[])
{
    char buf[10];
        char c;
        int j = rand();
        
    if (j > 5){
        /* Uninitialized Variable warning on next line */      
        buf[0] = c;
        buf[1] = c;
    }
    else
        /* Uninitialized Variable warning on next line */
        buf[2] = c;
}

Uninitialized Variable warnings are triggered for two lines: buf[0] = c and buf[2] = c. In this case, unlike the previous example, there are places c could be initialized so that only one of these lines is executed with c initialized. Therefore, both warnings are displayed. However, there is no warning on line buf[1] = c - it will always be fixed by any initialization that fixes the problem on the previous line.