Page History

Software `Software vulnerabilities can result when a programmer fails to consider all possible data states.

Noncompliant Code Example (

...

if Chain)

This noncompliant code example fails to test for conditions where in which a is neither b nor c. This may be the correct behavior in this case, but failure to account for all the values of a can result in logic errors if a unexpectedly assumes a different value.

if (a == b) {
  /* ... */
}
else if (a == c) {
  /* ... */
}

Compliant Solution (

...

if Chain)

This compliant solution explicitly checks for the unexpected condition and handles it appropriately.:

if (a == b) {
  /* ... */
}
else if (a == c) {
  /* ... */
}
else {
  /* handleHandle error condition */
}

Noncompliant Code Example (

...

switch)

Even though x is supposed to represent a bit (0 or 1) in the this noncompliant code belowexample, some previous error may have allowed x to assume a different value.
Detecting and dealing with that inconsistent state now sooner rather than later will make makes the error easier to find and may prevent security violations.

switch(x) {
  case 0: foo(); break;
  case 1: bar(); break;
}

Compliant Solution (

...

switch)

The This compliant solution below takes care to provide provides the default label to handle all valid possible values of type int:

switch(x) {
  case 0: foo(); break;
  case 1: bar(); break;

}
const char* f(Color c) {
  switch (c) {
    case Red: return "Red";
    case Green: return "Green";
    case Blue: return "Blue";
    default: return "Unknown color";   /* Handle necessaryerror */
  }
}

Note that adding a default case to a switch statement, even when all possible switch labels are specified, is exception (MSC07-EX1) to recommendation MSC07-C. Detect and remove dead code.

An alternative compliant solution to the noncompliant code example above is to provide a return statement after the switch statement. Note, however, that this solution may not be appropriate in all situations.

typedef enum { Red, Green, Blue } Color;
const char* f(Color c) {
  switch (c) {
    case Red: return "Red";
    case Green: return "Green";
    case Blue: return "Blue";
  }
  return "Unknown color";   /* necessary */
}

Historical Discussion

This practice has been a subject of debate for some time, but a clear direction has emerged.

Originally, the consensus among those writing best practices was simply that each switch statement should have a default label. Eventually, emerging compilers and static analysis tools could verify that a switch on an enum type contained a case label for each enumeration value, but only if no default label existed. This led to a shift toward purposely leaving out the default label to allow static analysis. However, the resulting code was then vulnerable to enum variables being assigned int values outside the set of enum values.

These two practices have now been merged. A switch on an enum type should now contain a case label for each enum value, but should also contain a default label for safety. This is not more difficult to analyze statically.

...

 break;
} 

Noncompliant Code Example (Zune 30)

This noncompliant code example shows incomplete logic when converting dates. The code is adapted from C code that appeared in the Zune 30 media player, causing many players to lock up on December 30, 2008, at midnight PST. This noncompliant code example comes from the ConvertDays function in the real-time clock (RTC) routines for the MC13783 PMIC RTC. This noncompliant code sample takes the number of days since January 1, 1980, and computes the correct year and number of days since January 1 of the correct year.The flaw in the code occurs when days has the value 366 because the loop never terminates. This bug manifested itself on the 366th day of 2008, which was the first leap year in which this code was activeIt contains incomplete logic that causes a denial of service when converting dates.

#definefinal ORIGINYEARstatic 1980
UINT32 daysint ORIGIN_YEAR = 1980;
/* numberNumber of days since January 1, 1980 */
public void convertDays(long days){  
	int year = ORIGINYEARORIGIN_YEAR;
    /* ... */

    while (days > 365) {
    	if (IsLeapYear(year)) {
        	if (days > 366) {
            	days -= 366;
              	year += 1;
            }
        }
  else {
            days -= 365;
            year += 1;
        }
    }
}

The original ConvertDays() function in the real-time clock (RTC) routines for the MC13783 PMIC RTC takes the number of days since January 1, 1980, and computes the correct year and number of days since January 1 of the correct year.

The flaw in the code occurs when days has the value 366 because the loop never terminates. This bug manifested itself on the 366th day of 2008, which was the first leap year in which this code was active.

Compliant Solution (Zune 30)

This proposed rewrite is provided by http://www.aeroxp.org/2009/01/lesson-on-infinite-loopsby "A Lesson on Infinite Loops" by Bryant Zadegan [Zadegan 2009]. The loop is guaranteed to exit, as days decreases for each iteration of the loop, unless the while condition fails, and in which case the loop terminates.

#define ORIGINYEARfinal static int ORIGIN_YEAR = 1980
UINT32;
/* Number of days =since /*January input1, parameter1980 */
public void convertDays(long days){    
	int year = ORIGINYEARORIGIN_YEAR;
    /* ... */

    int daysThisYear = (IsLeapYear(year) ? 366 : 365);
    while (days > daysThisYear) {
    	days -= daysThisYear;
        year += 1;
        daysThisYear = (IsLeapYear(year) ? 366 : 365);
    }
}

This compliant solution is for illustrative purposes and is not necessarily may differ from the solution implemented by Microsoft.

...

Applicability

Failing to take into account all possibilities within a logic statement can lead to a corrupted running state, potentially resulting in unintentional information disclosure or abnormal termination.

...

Recommendation

...

Severity

...

Likelihood

...

Remediation Cost

...

Priority

...

Level

...

MSC01-C

...

medium

...

probable

...

medium

...

P8

...

Automated Detection

  if (x > 0) {
	  /* ... */
  } else if (x < 0) {
    /* ... */
  } else if (x == 0) {
    /* ... */
  }

Related Vulnerabilities

...

Related Guidelines

...

...

...

...

Bibliography

...

...

[

...

Hatton

...

1995

...

]

§2.7.2,

...

"Errors

...

of

...

Omission and Addition"

[Viega

...

2005

...

]

§5.2.17,

...

"Failure

...

to Account for Default Case in Switch"
[Zadegan 2009]	A Lesson on Infinite Loops

...

Image Added Image Added Image Added account for default case in switch" \[[http://www.aeroxp.org/2009/01/lesson-on-infinite-loops]\] for analysis on the Zune 30 bugMSC00-C. Compile cleanly at high warning levels      49. Miscellaneous (MSC)      MSC02-C. Avoid errors of omission