Baseline for Ed 2 of tr 24772

6.9 Unchecked Array Indexing [XYZ]

6.9.1 Description of application vulnerability

Unchecked array indexing occurs when a value is used as an index into an array without checking that it falls within the acceptable index range.

6.9.2 Cross reference

CWE:

129. Unchecked Array Indexing

676. Use of Potentially Dangerous Function

JSF AV Rules: 164 and 15

MISRA C 2012: 21.1

MISRA C++ 2008: 5-0-15 to 5-0-18

CERT C guidelines: ARR30-C, ARR32-C, ARR33-C, and ARR38-C

Ada Quality and Style Guide: 5.5.1, 5.5.2, 7.6.7, and 7.6.8

6.9.3 Mechanism of failure

A single fault could allow both an overflow and underflow of the array index. An index overflow exploit might use buffer overflow techniques, but this can often be exploited without having to provide "large inputs." Array index overflows can also trigger out-of-bounds read operations, or operations on the wrong objects; that is, "buffer overflows" are not always the result. Unchecked array indexing, depending on its instantiation, can be responsible for any number of related issues. Most prominent of these possible flaws is the buffer overflow condition, with consequences ranging from denial of service, and data corruption, to arbitrary code execution. The most common situation leading to unchecked array indexing is the use of loop index variables as buffer indexes. If the end condition for the loop is subject to a flaw, the index can grow or shrink unbounded, therefore causing a buffer overflow or underflow. Another common situation leading to this condition is the use of a function's return value, or the resulting value of a calculation directly as an index in to a buffer. Unchecked array indexing can result in the corruption of relevant memory and perhaps instructions, lead to the program halting, if the values are outside of the valid memory area. If the memory corrupted is data, rather than instructions, the system might continue to function with improper values. If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code, as with a standard buffer overflow.

Language implementations might or might not statically detect out of bound access and generate a compile-time diagnostic. At runtime the implementation might or might not detect the out-of-bound access and provide a notification. The notification might be treatable by the program or it might not be. Accesses might violate the bounds of the entire array or violate the bounds of a particular index. It is possible that the former is checked and detected by the implementation while the latter is not. The information needed to detect the violation might or might not be available depending on the context of use. (For example, passing an array to a subroutine via a pointer might deprive the subroutine of information regarding the size of the array.)

Aside from bounds checking, some languages have ways of protecting against out-of-bounds accesses. Some languages automatically extend the bounds of an array to accommodate accesses that might otherwise have been beyond the bounds. However, this may or may not match the programmer's intent and can mask errors. Some languages provide for whole array operations that may obviate the need to access individual elements thus preventing unchecked array accesses.

6.9.4 Applicable language characteristics

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

• 
  Languages that do not automatically bounds check array accesses.
  
• 
  Languages that do not automatically extend the bounds of an array to accommodate array accesses.
  

6.9.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Include sanity checks to ensure the validity of any values used as index variables.
  
• 
  The choice could be made to use a language that is not susceptible to these issues.
  
• 
  When available, use whole array operations whenever possible.
  

6.9.6 Implications for standardization

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

• 
  Languages should consider providing compiler switches or other tools to check the size and bounds of arrays and their extents that are statically determinable.
  
• 
  Languages should consider providing whole array operations that may obviate the need to access individual elements.
  
• 
  Languages should consider the capability to generate exceptions or automatically extend the bounds of an array to accommodate accesses that might otherwise have been beyond the bounds.
  

6.10 Unchecked Array Copying [XYW]

6.10.1 Description of application vulnerability

A buffer overflow occurs when some number of bytes (or other units of storage) is copied from one buffer to another and the amount being copied is greater than is allocated for the destination buffer.

6.10.2 Cross reference

CWE:

121. Stack-based Buffer Overflow

JSF AV Rule: 15

MISRA C 2012: 21.1

MISRA C++ 2008: 5-0-15 to 5-0-18

CERT C guidelines: ARR33-C and STR31-C

Ada Quality and Style Guide: 7.6.7 and 7.6.8

6.10.3 Mechanism of failure

Many languages and some third party libraries provide functions that efficiently copy the contents of one area of storage to another area of storage. Most of these libraries do not perform any checks to ensure that the copied from/to storage area is large enough to accommodate the amount of data being copied.

The arguments to these library functions include the addresses of the contents of the two storage areas and the number of bytes (or some other measure) to copy. Passing the appropriate combination of incorrect start addresses or number of bytes to copy makes it possible to read or write outside of the storage allocated to the source/destination area. When passed incorrect parameters the library function performs one or more unchecked array index accesses, as described in 6.9 Unchecked Array Indexing [XYZ].

6.10.4 Applicable language characteristics

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

• 
  Languages that contain standard library functions for performing bulk copying of storage areas.
  
• 
  The same range of languages having the characteristics listed in 6.9 Unchecked Array Indexing [XYZ].
  

6.10.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Only use library functions that perform checks on the arguments to ensure no buffer overrun can occur (perhaps by writing a wrapper for the Standard provided functions). Perform checks on the argument expressions prior to calling the Standard library function to ensure that no buffer overrun will occur.
  
• 
  Use static analysis to verify that the appropriate library functions are only called with arguments that do not result in a buffer overrun. Such analysis may require that source code contain certain kinds of information, for example, that the bounds of all declared arrays be explicitly specified, or that pre- and post-conditions be specified as annotations or language constructs.
  

6.10.6 Implications for standardization

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

• 
  Languages should consider only providing libraries that perform checks on the parameters to ensure that no buffer overrun can occur.
  
• 
  Languages should consider providing full array assignment.