Baseline for Ed 2 of tr 24772

6.29 Loop Control Variables [TEX]

6.29.1 Description of application vulnerability

Many languages support a looping construct whose number of iterations is controlled by the value of a loop control variable. Looping constructs provide a method of specifying an initial value for this loop control variable, a test that terminates the loop and the quantity by which it should be decremented or incremented on each loop iteration.

In some languages it is possible to modify the value of the loop control variable within the body of the loop. Experience shows that such value modifications are sometimes overlooked by readers of the source code, resulting in faults being introduced.

Some languages, such as C and C++ do not explicitly specify which of the variables appearing in a loop header is the control variable for the loop. MISRA C [12] and MISRA C++ [16] have proposed algorithms for deducing which, if any, of these variables is the loop control variable in the programming languages C and C++ (these algorithms could also be applied to other languages that support a C-like for-loop).

6.29.2 Cross reference

JSF AV Rule: 201

MISRA C 2012: 14.2

MISRA C++ 2008: 6-5-1 to 6-5-6

6.29.3 Mechanism of failure

Readers of source code often make assumptions about what has been written. A common assumption is that a loop control variable is not modified in the body of the loop. A programmer may write incorrect code based on this assumption.

6.29.4 Applicable language characteristics

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

• 
  Languages that allow a loop control variable to be modified in the body of its associated loop.
  

6.29.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Do not modify a loop control variable in the body of its associated loop body.
  
• 
  Use a static analysis tool that identifies the modification of a loop control variable.
  

6.29.6 Implications for standardization

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

• 
  Language designers should consider the addition of an identifier type for loop control that cannot be modified by anything other than the loop control construct.
  

6.30 Off-by-one Error [XZH]

6.30.1 Description of application vulnerability

A program uses an incorrect maximum or minimum value that is 1 more or 1 less than the correct value. This usually arises from one of a number of situations where the bounds as understood by the developer differ from the design, such as:

• 
  Confusion between the need for < and <= or > and >= in a test.
  
• 
  Confusion as to the index range of an algorithm, such as: beginning an algorithm at 1 when the underlying structure is indexed from 0; beginning an algorithm at 0 when the underlying structure is indexed from 1 (or some other start point); or using the length of a structure as its bound instead of the sentinel values.
  
• 
  Failing to allow for storage of a sentinel value, such as the NULL string terminator that is used in the C and C++ programming languages.
  

These issues arise from mistakes in mapping the design into a particular language, in moving between languages (such as between languages where all arrays start at 0 and other languages where arrays start at 1), and when exchanging data between languages with different default array bounds.

The issue also can arise in algorithms where relationships exist between components, and the existence of a bounds value changes the conditions of the test.

The existence of this possible flaw can also be a serious security hole as it can permit someone to surreptitiously provide an unused location (such as 0 or the last element) that can be used for undocumented features or hidden channels.

6.30.2 Cross reference

CWE:

193. Off-by-one Error

6.30.3 Mechanism of failure

An off-by-one error could lead to:

• 
  an out-of bounds access to an array (buffer overflow),
  
• 
  incomplete comparisons or calculation mistakes,
  
• 
  a read from the wrong memory location, or
  
• 
  an incorrect conditional.
  

Such incorrect accesses can cause cascading errors or references to invalid locations, resulting in potentially unbounded behaviour.

Off-by-one errors are not often exploited in attacks because they are difficult to identify and exploit externally, but the cascading errors and boundary-condition errors can be severe.

6.30.4 Applicable language characteristics

As this vulnerability arises because of an algorithmic error by the developer, it can in principle arise in any language; however, it is most likely to occur when:

• 
  The language relies on the developer having implicit knowledge of structure start and end indices (for example, knowing whether arrays start at 0 or 1 – or indeed some other value).
  
• 
  Where the language relies upon explicit bounds values to terminate variable length arrays.
  

6.30.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Follow a systematic development process, use of development/analysis tools and thorough testing are all common ways of preventing errors, and in this case, off-by-one errors.
  
• 
  Use static analysis tools that warn of potential off-by-one errors.
  

• 
  Where references are being made to array indices and the languages provide ways to specify the whole array or the starting and ending indices explicitly (for example, Ada provides xxx'First and xxx'Last for each dimension), these should be used always. Where the language doesn't provide these, constants can be declared and used in preference to numeric literals.
  

• 
  Where the language doesn’t encapsulate variable length arrays, encapsulation should be provided through library objects and a coding standard developed that requires such arrays to only be used via those library objects, so the developer does not need to be explicitly concerned with managing bounds values.
  

6.30.6 Implications for standardization

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

• 
  Languages should provide encapsulations for arrays that:
  
  • 
    Prevent the need for the developer to be concerned with explicit bounds values.
    
  • 
    Provide the developer with symbolic access to the array start, end and iterators.