Baseline for Ed 2 of tr 24772

6.7 String Termination [CJM]

6.7.1 Description of application vulnerability

Some programming languages use a termination character to indicate the end of a string. Relying on the occurrence of the string termination character without verification can lead to either exploitation or unexpected behaviour.

6.7.2 Cross reference

CWE:

170. Improper Null Termination

CERT C guidelines: STR03-C, STR31-C, STR32-C, and STR36-C

6.7.3 Mechanism of failure

String termination errors occur when the termination character is solely relied upon to stop processing on the string and the termination character is not present. Continued processing on the string can cause an error or potentially be exploited as a buffer overflow. This may occur as a result of a programmer making an assumption that a string that is passed as input or generated by a library contains a string termination character when it does not.

Programmers may forget to allocate space for the string termination character and expect to be able to store an n length character string in an array that is n characters long. Doing so may work in some instances depending on what is stored after the array in memory, but it may fail or be exploited at some point.

6.7.4 Applicable language characteristics

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

• 
  Languages that use a termination character to indicate the end of a string.
  
• 
  Languages that do not do bounds checking when accessing a string or array.
  

6.7.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 rely solely on the string termination character.
  
• 
  Use library calls that do not rely on string termination characters such as strncpy instead of strcpy in the standard C library.
  
• 
  Use static analysis tools that detect errors in string termination.
  

6.7.6 Implications for standardization

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

• 
  Eliminating library calls that make assumptions about string termination characters.
  

• 
  Checking bounds when an array or string is accessed, see C Bounds Checking Library[13].
  
• 
  Specifying a string construct that does not need a string termination character.
  

6.8 Buffer Boundary Violation (Buffer Overflow) [HCB]

6.8.1 Description of application vulnerability

A buffer boundary violation arises when, due to unchecked array indexing or unchecked array copying, storage outside the buffer is accessed. Usually boundary violations describe the situation where such storage is then written. Depending on where the buffer is located, logically unrelated portions of the stack or the heap could be modified maliciously or unintentionally. Usually, buffer boundary violations are accesses to contiguous memory beyond either end of the buffer data, accessing before the beginning or beyond the end of the buffer data is equally possible, dangerous and maliciously exploitable.

6.8.2 Cross reference

CWE:

120. Buffer copy without Checking Size of Input (‘Classic Buffer Overflow’)

122. Heap-based Buffer Overflow

124. Boundary Beginning Violation (‘Buffer Underwrite’)

129. Unchecked Array Indexing

131. Incorrect Calculation of Buffer Size

787. Out-of-bounds Write

805. Buffer Access with Incorrect Length Value

JSF AV Rule: 15 and 25

MISRA C 2012: 21.1

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

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

6.8.3 Mechanism of failure

The program statements that cause buffer boundary violations are often difficult to find.

There are several kinds of failures (in all cases an exception may be raised if the accessed location is outside of some permitted range of the run-time environment):

• 
  A read access will return a value that has no relationship to the intended value, such as, the value of another variable or uninitialized storage.
  
• 
  An out-of-bounds read access may be used to obtain information that is intended to be confidential.
  
• 
  A write access will not result in the intended value being updated and may result in the value of an unrelated object (that happens to exist at the given storage location) being modified, including the possibility of changes in external devices resulting from the memory location being hardware-mapped.
  
• 
  When an array has been allocated storage on the stack an out-of-bounds write access may modify internal runtime housekeeping information (for example, a function's return address) which might change a program’s control flow.
  
• 
  An inadvertent or malicious overwrite of function pointers that may be in memory, causing them to point to an unexpected location or the attacker's code. Even in applications that do not explicitly use function pointers, the run-time will usually store pointers to functions in memory. For example, object methods in object-oriented languages are generally implemented using function pointers in a data structure or structures that are kept in memory. The consequence of a buffer boundary violation can be targeted to cause arbitrary code execution; this vulnerability may be used to subvert any security service.
  

6.8.4 Applicable language characteristics

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

• 
  Languages that do not detect and prevent an array being accessed outside of its declared bounds (either by means of an index or by pointer0F¹).
  
• 
  Languages that do not automatically allocate storage when accessing an array element for which storage has not already been allocated.
  
• 
  Languages that provide bounds checking but permit the check to be suppressed.
  
• 
  Languages that allow a copy or move operation without an automatic length check ensuring that source and target locations are of at least the same size. The destination target can be larger than the source being copied.
  

6.8.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Use of implementation-provided functionality to automatically check array element accesses and prevent out-of-bounds accesses.
  
• 
  Use of static analysis to verify that all array accesses are within the permitted bounds. Such analysis may require that source code contain certain kinds of information, such as, that the bounds of all declared arrays be explicitly specified, or that pre- and post-conditions be specified.
  
• 
  Perform sanity checks on all calculated expressions used as an array index or for pointer arithmetic.
  
• 
  Ascertain whether or not the compiler can insert bounds checks while still meeting the performance requirements of the program and direct the compiler to insert such checks where appropriate
  

Some guideline documents recommend only using variables having an unsigned data type when indexing an array, on the basis that an unsigned data type can never be negative. This recommendation simply converts an indexing underflow to an indexing overflow because the value of the variable will wrap to a large positive value rather than a negative one. Also some languages support arrays whose lower bound is greater than zero, so an index can be positive and be less than the lower bound. Some languages support zero-sized arrays, so any reference to a location within such an array is invalid.

In the past the implementation of array bound checking has sometimes incurred what has been considered to be a high runtime overhead (often because unnecessary checks were performed). It is now practical for translators to perform sophisticated analysis that significantly reduces the runtime overhead (because runtime checks are only made when it cannot be shown statically that no bound violations can occur).

6.8.6 Implications for standardization

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

• 
  Languages should provide safe copying of arrays as built-in operation.
  
• 
  Languages should consider only providing array copy routines in libraries that perform checks on the parameters to ensure that no buffer overrun can occur.
  
• 
  Languages should perform automatic bounds checking on accesses to array elements, unless the compiler can statically determine that the check is unnecessary. This capability may need to be optional for performance reasons.
  

• 
  Languages that use pointer types should consider specifying a standardized feature for a pointer type that would enable array bounds checking.