Baseline for Ed 2 of tr 24772

6.5 Enumerator Issues [CCB]

6.5.1 Description of application vulnerability

Enumerations are a finite list of named entities that contain a fixed mapping from a set of names to a set of integral values (called the representation) and an order between the members of the set. In some languages there are no other operations available except order, equality, first, last, previous, and next; in others the full underlying representation operators are available, such as integer “+” and “-” and bit-wise operations.

Most languages that provide enumeration types also provide mechanisms to set non-default representations. If these mechanisms do not enforce whole-type operations and check for conflicts then some members of the set may not be properly specified or may have the wrong mappings. If the value-setting mechanisms are positional only, then there is a risk that improper counts or changes in relative order will result in an incorrect mapping.

For arrays indexed by enumerations with non-default representations, there is a risk of structures with holes, and if those indexes can be manipulated numerically, there is a risk of out-of-bound accesses of these arrays.

Most of these errors can be readily detected by static analysis tools with appropriate coding standards, restrictions and annotations. Similarly mismatches in enumeration value specification can be detected statically. Without such rules, errors in the use of enumeration types are computationally hard to detect statically as well as being difficult to detect by human review.

6.5.2 Cross reference

JSF AV Rule:

MISRA C 2012: 8.12, 9.2, and 9.3

MISRA C++ 2008: 8-5-3

CERT C guidelines: INT09-C

Holzmann rule 6

Ada Quality and Style Guide: 3.4.2

6.5.3 Mechanism of failure

As a program is developed and maintained the list of items in an enumeration often changes in three basic ways: new elements are added to the list; order between the members of the set often changes; and representation (the map of values of the items) change. Expressions that depend on the full set or specific relationships between elements of the set can create value errors that could result in wrong results or in unbounded behaviours if used as array indices.

Improperly mapped representations can result in some enumeration values being unreachable, or may create “holes” in the representation where values that cannot be defined are propagated.

If arrays are indexed by enumerations containing non-default representations, some implementations may leave space for values that are unreachable using the enumeration, with a possibility of unnecessarily large memory allocations or a way to pass information undetected (hidden channel).

When enumerators are set and initialized explicitly and the language permits incomplete initializers, then changes to the order of enumerators or the addition or deletion of enumerators can result in the wrong values being assigned or default values being assigned improperly. Subsequent indexing can result in invalid accesses and possibly unbounded behaviours.

6.5.4 Applicable language Characteristics

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

• 
  Languages that permit incomplete mappings between enumerator specification and value assignment, or that provide a positional-only mapping require additional static analysis tools and annotations to help identify the complete mapping of every literal to its value.
  
• 
  Languages that provide a trivial mapping to a type such as integer require additional static analysis tools to prevent mixed type errors. They also cannot prevent invalid values from being placed into variables of such enumerator types. For example:
  

enum Directions {back, forward, stop};
enum Directions a = forward, b = stop, c = a + b;

In this example, c may have a value not defined by the enumeration, and any further use as that enumeration will lead to erroneous results.

• 
  Some languages provide no enumeration capability, leaving it to the programmer to define named constants to represent the values and ranges.
  

6.5.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Use static analysis tools that will detect inappropriate use of enumerators, such as using them as integers or bit maps, and that detect enumeration definition expressions that are incomplete or incorrect. For languages with a complete enumeration abstraction this is the compiler.
  
• 
  In code that performs different computations depending on the value of an enumeration, ensure that each possible enumeration value is covered, or provide a default that raises an error or exception.
  
• 
  Use an enumerated type to select from a limited set of choices and use tools that statically detect omissions of possible values in an enumeration
  

6.5.6 Implications for standardization

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

• 
  Languages that currently permit arithmetic and logical operations on enumeration types could provide a mechanism to ban such operations program-wide.
  
• 
  Languages that provide automatic defaults or that do not enforce static matching between enumerator definitions and initialization expressions could provide a mechanism to enforce such matching.
  

6.6 Conversion Errors [FLC]

6.6.1 Description of application vulnerability

Certain contexts in various languages may require exact matches with respect to types [32]:

aVar := anExpression

value1 + value2

foo(arg1, arg2, arg3, … , argN)

Type conversion seeks to follow these exact match rules while allowing programmers some flexibility in using values such as: structurally-equivalent types in a name-equivalent language, types whose value ranges may be distinct but intersect (for example, subranges), and distinct types with sensible/meaningful corresponding values (for example, integers and floats).

Conversions can lead to a loss of data, if the target representation is not capable of representing the original value. For example, converting from an integer type to a smaller integer type can result in truncation if the original value cannot be represented in the smaller size and converting a floating point to an integer can result in a loss of precision or an out-of-range value. Converting from a character type to a smaller character type can result in the misrepresentation of the character.

Type-conversion errors can lead to erroneous data being generated, algorithms that fail to terminate, array bounds-errors, or arbitrary program execution.

See also {OO} for upcasting errors.

6.6.2 Cross reference

CWE: 192. Integer Coercion Error

MISRA C 2012: 7.2, 10.1, 10.3, 10.4, 10.6-10.8, and 11.1-11.8

MISRA C++ 2008: 2-13-3, 5-0-3, 5-0-4, 5-0-5, 5-0-6, 5-0-7, 5-0-8, 5-0-9, 5-0-10, 5-2-5, 5-2-9, and 5-3-2

CERT C guidelines: FLP34-C, INT02-C, INT08-C, INT31-C, and INT35-C

6.6.3 Mechanism of failure

Conversion errors result in data integrity issues, and may also result in a number of safety and security vulnerabilities.

When the conversion results in no change in representation but a change in value for the new type, this may result in a value that is not expressible in the new type, or that has a dramatically different order or meaning. One such situation is the change of sign between the origin and destination (negative -> positive or positive -> negative), which changes the relative order of members of the two types and could result in memory access failures if the values are used in address calculations. Numeric type conversions can be less obvious because some languages will silently convert between numeric types.

Vulnerabilities typically occur when appropriate range checking is not performed, and unanticipated values are encountered. These can result in safety issues, for example, when the Ariane 5 launcher failure occurred due to an improperly handled conversion error resulting in the processor being shutdown [29].

Conversion errors can also result in security issues. An attacker may input a particular numeric value to exploit a flaw in the program logic. The resulting erroneous value may then be used as an array index, a loop iterator, a length, a size, state data, or in some other security-critical manner. For example, a truncated integer value may be used to allocate memory, while the actual length is used to copy information to the newly allocated memory, resulting in a buffer overflow [30].

Numeric type-conversion errors can lead to undefined states of execution resulting in infinite loops or crashes. In some cases, integer type-conversion errors can lead to exploitable buffer overflow conditions, resulting in the execution of arbitrary code. Integer type-conversion errors result in an incorrect value being stored for the variable in question.

6.6.4 Applicable language characteristics

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

• 
  Languages that perform implicit type conversion (coercion).
  
• 
  Languages that permit conversions between subtypes of a polymorphic type. See [???] Upcasts and downcasts
  
• 
  Weakly typed languages that do not strictly enforce type rules.
  
• 
  Languages that support logical, arithmetic, or circular shifts on integer values.
  
• 
  Languages that do not generate exceptions on problematic conversions.
  

6.6.5 Avoiding the vulnerability or mitigating its effects

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

• 
  If range checking is not provided by the language, use explicit range checks, type checks or value checks to validate the correctness of all values originating from a source that is not trusted. However, it is difficult to guarantee that multiple input variables cannot be manipulated to cause an error to occur in some operation somewhere in a program [30].
  
• 
  Alternatively, use explicit range checks to protect each operation. Because of the large number of integer operations that are susceptible to these problems and the number of checks required to prevent or detect exceptional conditions, this approach can be prohibitively labor intensive and expensive to implement.
  
• 
  Choose a language that generates exceptions on erroneous data conversions.
  
• 
  Design objects and program flow such that multiple or complex explicit type conversions are unnecessary. Understand any explicit type conversion that you must use to reduce the plausibility of error in use.
  
• 
  Use static analysis tools to identify whether or not unacceptable conversions will occur, to the extent possible.
  
• 
  Avoid the use of “plausible but wrong” default values when a calculation cannot be completed correctly. Either generate an error or produce a value that is out of range and is certain to be detected. Take care that any error processing does not lead to a denial-of-service vulnerability.
  

6.6.6 Implications for standardization

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

• 
  Languages should provide mechanisms to prevent programming errors due to conversions.
  
• 
  Languages should consider making all type-conversions explicit or at least generating warnings for implicit conversions where loss of data might occur.