Baseline for Ed 2 of tr 24772

6.15 Arithmetic Wrap-around Error [FIF]

6.15.1 Description of application vulnerability

Wrap-around errors can occur whenever a value is incremented past the maximum or decremented past the minimum value representable in its type and, depending upon

• 
  whether the type is signed or unsigned,
  
• 
  the specification of the language semantics and/or
  
• 
  implementation choices,
  

"wraps around" to an unexpected value. This vulnerability is related to 6.16 Using Shift Operations for Multiplication and Division [PIK]³.

6.15.2 Cross reference

CWE:

128. Wrap-around Error

190. Integer Overflow or Wraparound

JSF AV Rules: 164 and 15

MISRA C 2012: 7.2, 10.1, 10.3, 10.4, 10.6, 10.7, and 12.4

MISRA C++ 2008: 2-13-3, 5-0-3 to 5-0-10, and 5-19-1

CERT C guidelines: INT30-C, INT32-C, and INT34-C

6.15.3 Mechanism of failure

Due to how arithmetic is performed by computers, if a variable’s value is increased past the maximum value representable in its type, the system may fail to provide an overflow indication to the program. One of the most common processor behaviour is to “wrap” to a very large negative value, or set a condition flag for overflow or underflow, or saturate at the largest representable value.

Wrap-around often generates an unexpected negative value; this unexpected value may cause a loop to continue for a long time (because the termination condition requires a value greater than some positive value) or an array bounds violation. A wrap-around can sometimes trigger buffer overflows that can be used to execute arbitrary code.

It should be noted that the precise consequences of wrap-around differ depending on:

• 
  Whether the type is signed or unsigned.
  
• 
  Whether the type is a modulus type.
  
• 
  Whether the type’s range is violated by exceeding the maximum representable value or falling short of the minimum representable value.
  
• 
  The semantics of the language specification.
  
• 
  Implementation decisions.
  

However, in all cases, the resulting problem is that the value yielded by the computation may be unexpected.

6.15.4 Applicable language characteristics

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

• 
  Languages that do not trigger an exception condition when a wrap-around error occurs.
  

6.15.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Determine applicable upper and lower bounds for the range of all variables and use language mechanisms or static analysis to determine that values are confined to the proper range.
  
• 
  Analyze the software using static analysis looking for unexpected consequences of arithmetic operations.
  

6.15.6 Implications for standardization

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

• 
  Language standards developers should consider providing facilities to specify either an error, a saturated value, or a modulo result when numeric overflow occurs. Ideally, the selection among these alternatives could be made by the programmer.
  

6.16 Using Shift Operations for Multiplication and Division [PIK]

6.16.1 Description of application vulnerability

Using shift operations as a surrogate for multiply or divide may produce an unexpected value when the sign bit is changed or when value bits are lost. This vulnerability is related to 6.15 Arithmetic Wrap-around Error [FIF]⁴.

6.16.2 Cross reference

CWE:

128. Wrap-around Error

190. Integer Overflow or Wraparound

JSF AV Rules: 164 and 15

MISRA C 2012: 7.2, 10.1, 10.3, 10.4, 10.6, 10.7, and 12.4

MISRA C++ 2008: 2-13-3, 5-0-3 to 5-0-10, and 5-19-1

CERT C guidelines: INT30-C, INT32-C, and INT34-C

6.16.3 Mechanism of failure

Shift operations intended to produce results equivalent to multiplication or division fail to produce correct results if the shift operation affects the sign bit or shifts significant bits from the value.

Such errors often generate an unexpected negative value; this unexpected value may cause a loop to continue for a long time (because the termination condition requires a value greater than some positive value) or an array bounds violation. The error can sometimes trigger buffer overflows that can be used to execute arbitrary code.

6.16.4 Applicable language characteristics

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

• 
  Languages that permit logical shift operations on variables of arithmetic type.
  

6.16.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Determine applicable upper and lower bounds for the range of all variables and use language mechanisms or static analysis to determine that values are confined to the proper range.
  
• 
  Analyze the software using static analysis looking for unexpected consequences of shift operations.
  
• 
  Avoid using shift operations as a surrogate for multiplication and division. Most compilers will use the correct operation in the appropriate fashion when it is applicable.
  

6.16.6 Implications for standardization

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

• 
  Not providing logical shifting on arithmetic values or flagging it for reviewers.
  

6.17 Choice of Clear Names [NAI].

6.17.1 Description of application vulnerability

Humans sometimes choose similar or identical names for objects, types, aggregates of types, subprograms and modules. They tend to use characteristics that are specific to the native language of the software developer to aid in this effort, such as use of mixed-casing, underscores and periods, or use of plural and singular forms to support the separation of items with similar names. Similarly, development conventions sometimes use casing for differentiation (for example, all uppercase for constants).

Human cognitive problems occur when different (but similar) objects, subprograms, types, or constants differ in name so little that human reviewers are unlikely to distinguish between them, or when the system maps such entities to a single entity.

Conventions such as the use of capitalization, and singular/plural distinctions may work in small and medium projects, but there are a number of significant issues to be considered:

• 
  Large projects often have mixed languages and such conventions are often language-specific.
  
• 
  Many implementations support identifiers that contain international character sets and some language character sets have different notions of casing and plurality.
  
• 
  Different word-forms tend to be language and dialect specific, such as a pidgin, and may be meaningless to humans that speak other dialects.
  

An important general issue is the choice of names that differ from each other negligibly (in human terms), for example by differing by only underscores, (none, "_" "__"), plurals ("s"), visually similar characters (such as "l" and "1", "O" and "0"), or underscores/dashes ("-","_"). [There is also an issue where identifiers appear distinct to a human but identical to the computer, such as FOO, Foo, and foo in some computer languages.] Character sets extended with diacritical marks and non-Latin characters may offer additional problems. Some languages or their implementations may pay attention to only the first n characters of an identifier.

The problems described above are different from overloading or overriding where the same name is used intentionally (and documented) to access closely linked sets of subprograms. This is also different than using reserved names which can lead to a conflict with the reserved use and the use of which may or may not be detected at compile time.

Name confusion can lead to the application executing different code or accessing different objects than the writer intended, or than the reviewers understood. This can lead to outright errors, or leave in place code that may execute sometime in the future with unacceptable consequences.

Although most such mistakes are unintentional, it is plausible that such usages can be intentional, if masking surreptitious behaviour is a goal.

6.17.2 Cross reference

JSF AV Rules: 48, 49, 50, 51,52

MISRA C 2012: 1.1

CERT C guidelines: DCL02-C

Ada Quality and Style Guide: 3.2

6.17.3 Mechanism of Failure

Calls to the wrong subprogram or references to the wrong data element (that was missed by human review) can result in unintended behaviour. Language processors will not make a mistake in name translation, but human cognition limitations may cause humans to misunderstand, and therefore may be missed in human reviews.

6.17.4 Applicable language characteristics

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

• 
  Languages with relatively flat name spaces will be more susceptible. Systems with modules, classes, packages can use qualification to disambiguate names that originate from different parents.
  
• 
  Languages that provide preconditions, post conditions, invariances and assertions or redundant coding of subprogram signatures help to ensure that the subprograms in the module will behave as expected, but do nothing if different subprograms are called.
  
• 
  Languages that treat letter case as significant. Some languages do not differentiate between names with differing case, while others do.
  

6.17.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 to show the target of calls and accesses and to produce alphabetical lists of names. Human review can then often spot the names that are sorted at an unexpected location or which look almost identical to an adjacent name in the list.
  
• 
  Use languages with a requirement to declare names before use or use available tool or compiler options to enforce such a requirement.
  
• 
  Do not choose names that conflict with (unreserved) keywords or language-defined library names for the language being used.
  
• 
  Do not use names that only differ by characters that may be confused visually in the alphabet used in development. For the Roman alphabet these would include as ‘O’ and ‘0’, ‘l’ (lower case ‘L’), ‘I’ (capital ‘I’) and ‘1’, ‘S’ and ‘5’, ‘Z’ and ‘2’, and ‘n’ and ‘h’.
  
• 
  Do not use names that only differ in the use of upper and lower case to other names
  

6.17.6 Implications for standardization

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

• 
  Languages that do not require declarations of names should consider providing an option that does impose that requirement.