Baseline for Ed 2 of tr 24772

6.11 Pointer Type Conversions [HFC]

6.11.1 Description of application vulnerability

The code produced for access via a data or function pointer requires that the type of the pointer is appropriate for the data or function being accessed. Otherwise undefined behaviour can occur. Specifically, “access via a data pointer” is defined to be “fetch or store indirectly through that pointer” and “access via a function pointer” is defined to be “invocation indirectly through that pointer.” The detailed requirements for what is meant by the “appropriate” type may vary among languages.

Even if the type of the pointer is appropriate for the access, erroneous pointer operations can still cause a fault.

6.11.2 Cross reference

CWE:

136. Type Errors

188. Reliance on Data/Memory Layout

JSF AV Rules: 182 and 183

MISRA C 2012: 11.1-11.8

MISRA C++ 2008: 5-2-2 to 5-2-9

CERT C guidelines: INT11-C and EXP36-A

Hatton 13: Pointer casts

Ada Quality and Style Guide: 7.6.7 and 7.6.8

6.11.3 Mechanism of failure

If a pointer’s type is not appropriate for the data or function being accessed, data can be corrupted or privacy can be broken by inappropriate read or write operation using the indirection provided by the pointer value. With a suitable type definition, large portions of memory can be maliciously or accidentally modified or read. Such modification of data objects will generally lead to value faults of the application. Modification of code elements such as function pointers or internal data structures for the support of object-orientation can affect control flow. This can make the code susceptible to targeted attacks by causing invocation via a pointer-to-function that has been manipulated to point to an attacker’s malicious code.

6.11.4 Applicable language characteristics

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

• 
  Pointers (and/or references) can be converted to different pointer types.
  
• 
  Pointers to functions can be converted to pointers to data.
  

6.11.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Treat the compiler’s pointer-conversion warnings as serious errors.
  
• 
  Adopt programming guidelines (preferably augmented by static analysis) that restrict pointer conversions. For example, consider the rules itemized above from JSF AV [15], CERT C [11], Hatton [18], or MISRA C [12].
  
• 
  Use other means of assurance such as proofs of correctness, analysis with tools, verification techniques, or other methods to check that pointer conversions do not lead to later undefined behaviour.
  

6.11.6 Implications for standardization

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

• 
  Languages should consider creating a mode that provides a runtime check of the validity of all accessed objects before the object is read, written or executed.
  

6.12 Pointer Arithmetic [RVG]

6.12.1 Description of application vulnerability

Using pointer arithmetic incorrectly can result in addressing arbitrary locations, which in turn can cause a program to behave in unexpected ways.

6.12.2 Cross reference

JSF AV Rule: 215

MISRA C 2012: 18.1-18.4

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

CERT C guidelines: EXP08-C

6.12.3 Mechanism of failure

Pointer arithmetic used incorrectly can produce:

• 
  Addressing arbitrary memory locations, including buffer underflow and overflow.
  
• 
  Arbitrary code execution.
  
• 
  Addressing memory outside the range of the program.
  

6.12.4 Applicable language characteristics

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

• 
  Languages that allow pointer arithmetic.
  

6.12.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Avoid using pointer arithmetic for accessing anything except composite types.
  
• 
  Prefer indexing for accessing array elements rather than using pointer arithmetic.
  
• 
  Limit pointer arithmetic calculations to the addition and subtraction of integers.
  

6.12.6 Implications for standardization

[None]

6.13 Null Pointer Dereference [XYH]

6.13.1 Description of application vulnerability

A null-pointer dereference takes place when a pointer with a value of NULL is used as though it pointed to a valid memory location. This is a special case of accessing storage via an invalid pointer.

6.13.2 Cross reference

CWE:

476. NULL Pointer Dereference

JSF AV Rule 174

CERT C guidelines: EXP34-C

Ada Quality and Style Guide: 5.4.5

6.13.3 Mechanism of failure

When a pointer with a value of NULL is used as though it pointed to a valid memory location, then a null-pointer dereference is said to take place. This can result in a segmentation fault, unhandled exception, or accessing unanticipated memory locations.

6.13.4 Applicable language characteristics

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

• 
  Languages that permit the use of pointers and that do not check the validity of the location being accessed prior to the access.
  
• 
  Languages that allow the use of a NULL pointer.
  

6.13.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Before dereferencing a pointer, ensure it is not equal to NULL.
  

6.13.6 Implications for standardization

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

• 
  A language feature that would check a pointer value for NULL before performing an access should be considered.