Baseline for Ed 2 of tr 24772

6.27 Switch Statements and Static Analysis [CLL]

6.27.1 Description of application vulnerability

Many programming languages provide a construct, such as a C-like switch statement, that chooses among multiple alternative control flows based upon the evaluated result of an expression. The use of such constructs may introduce application vulnerabilities if not all possible cases appear within the switch or if control unexpectedly flows from one alternative to another.

6.27.2 Cross reference

JSF AV Rules: 148, 193, 194, 195, and 196

MISRA C 2012: 16.3-16.6

MISRA C++ 2008: 6-4-3, 6-4-5, 6-4-6, and 6-4-8
CERT C guidelines: MSC01-C

Ada Quality and Style Guide: 5.6.1 and 5.6.10

6.27.3 Mechanism of failure

The fundamental challenge when using a switch statement is to make sure that all possible cases are, in fact, treated correctly.

6.27.4 Applicable language characteristics

This vulnerability description is intended to be applicable to languages with the following characteristics:

• 
  Languages that contain a construct, such as a switch statement, that provides a selection among alternative control flows based on the evaluation of an expression.
  
• 
  Languages that do not require full coverage of all possible alternatives of a switch statement.
  
• 
  Languages that provide a default case (choice) in a switch statement.
  

6.27.5 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Ensure that every valid choice has a branch that covers the choice.
  
• 
  Avoid default branches where it can be statically shown that each choice is covered by a branch.
  
• 
  Use a default branch that initiates error processing where coverage of all choices by branches cannot be statically shown.
  
• 
  Use a restricted set of enumeration values to improve coverage analysis where the language provides such capability.
  
• 
  Avoid “flowing through” from one case to another. Even if correctly implemented, it is difficult for reviewers and maintainers to distinguish whether the construct was intended or is an error of omission3F⁵.
  
• 
  In cases where flow-through is necessary and intended, use an explicitly coded branch to clearly mark the intent. Provide comments explaining the intention can be helpful to reviewers and maintainers.
  
• 
  Perform static analysis to determine if all cases are, in fact, covered by the code. (Note that the use of a default case can hamper the effectiveness of static analysis since the tool cannot determine if omitted alternatives were or were not intended for default treatment.)
  
• 
  Use other means of mitigation including manual review, bounds testing, tool analysis, verification techniques, and proofs of correctness.
  

6.27.6 Implications for standardization

In future standardization activities, the following items should be considered:

• 
  Language specifications could require compilers to ensure that a complete set of alternatives is provided in cases where the value set of the switch variable can be statically determined.
  

6.28 Demarcation of Control Flow [EOJ]

6.28.1 Description of application vulnerability

Some programming languages explicitly mark the end of an if statement or a loop, whereas other languages mark only the end of a block of statements. Languages of the latter category are prone to oversights by the programmer, causing unintended sequences of control flow.

6.28.2 Cross reference

JSF AV Rules: 59 and 192
MISRA C 2012: 15.6 and 15.7

MISRA C++ 2008: 6-3-1, 6-4-1, 6-4-2, 6-4-3, 6-4-8, 6-5-1, 6-5-6, 6-6-1 to 6-6-5, and16-0-2

Hatton 18: Control flow – if structure

Ada Quality and Style Guide: 3, 5.6.1 through 5.6.10

6.28.3 Mechanism of failure

Programmers may rely on indentation to determine inclusion of statements within constructs. Testing of the software may not reveal that statements that appear to be included in a construct (due to formatting) actually lay outside of it because of the absence of a terminator. Moreover, for a nested if-then-else statement the programmer may be confused about which if statement controls the else part directly. This can lead to unexpected results.

6.28.4 Applicable language characteristics

This vulnerability description is intended to be applicable to languages with the following characteristics:

• 
  Languages that contain loops and conditional statements that are not explicitly terminated by an “end” construct.
  

6.28.5 Avoiding the vulnerability or mitigating its effects

Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:

• 
  Where the language does not provide demarcation of the end of a control structure, adopt a convention for marking the closing of a construct that can be checked by a tool, to ensure that program structure is apparent.
  
• 
  Adopt programming guidelines (preferably augmented by static analysis). For example, consider the rules documented in 6.29.2.
  
• 
  Use other means of assurance, such as proofs of correctness, analysis with tools, and dynamic verification techniques.
  
• 
  Use pretty-printers and syntax-aware editors to help find such problems. Be aware that such tools sometimes disguise such errors.
  
• 
  Where the language permits single statements after loops and conditional statements but permits optional compound statements (such as C
  

if (...) statement else statement;  

or Pascal

if expression then statement else statement;)

always use the compound version (i.e. C's { ... } or Pascal's begin ... end).

6.28.6 Implications for standardization

In future standardization activities, the following items should be considered:

• 
  Adding a mode that strictly enforces compound conditional and looping constructs with explicit termination, such as “end if” or a closing bracket.
  
• 
  Syntax for explicit termination of loops and conditional statements.
  
• 
  Features to terminate named loops and conditionals and determine if the structure as named matches the structure as inferred.