Baseline for Ed 2 of tr 24772

6.38 Type-breaking Reinterpretation of Data [AMV]

6.38.1 Description of application vulnerability

In most cases, objects in programs are assigned locations in processor storage to hold their value. If the same storage space is assigned to more than one object—either statically or temporarily—then a change in the value of one object will have an effect on the value of the other. Furthermore, if the representation of the value of an object is reinterpreted as being the representation of the value of an object with a different type, unexpected results may occur.

6.38.2 Cross reference

JSF AV Rules 153 and183

MISRA 2012: 19.1, and 19.2

MISRA C++ 2008: 4-5-1 to 4-5-3, 4-10-1, 4-10-2, and 5-0-3 to 5-0-9

CERT C guidelines: MEM08-C

Ada Quality and Style Guide: 7.6.7 and 7.6.8

6.38.3 Mechanism of failure

Sometimes there is a legitimate need for applications to place different interpretations upon the same stored representation of data. The most fundamental example is a program loader that treats a binary image of a program as data by loading it, and then treats it as a program by invoking it. Most programming languages permit type-breaking reinterpretation of data, however, some offer less error-prone alternatives for commonly encountered situations.

Type-breaking reinterpretation of representation presents obstacles to human understanding of the code, the ability of tools to perform effective static analysis, and the ability of code optimizers to do their job.

Examples include:

• 
  Providing alternative mappings of objects into blocks of storage performed either statically (such as Fortran common) or dynamically (such as pointers).
  
• 
  Union types, particularly unions that do not have a discriminant stored as part of the data structure.
  
• 
  Operations that permit a stored value to be interpreted as a different type (such as treating the representation of a pointer as an integer).
  

In all of these cases accessing the value of an object may produce an unanticipated result.

A related problem, the aliasing of parameters, occurs in languages that permit call by reference because supposedly distinct parameters might refer to the same storage area, or a parameter and a non-local object might refer to the same storage area. That vulnerability is described in Passing Parameters and Return Values [CSJ].

6.38.4 Applicable language characteristics

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

• 
  A programming language that permits multiple interpretations of the same bit pattern.
  

6.38.5 Avoiding the vulnerability or mitigating its effects

AI – Steve - fix

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

• 
  Avoid reinterpretation performed as a matter of convenience; for example, avoid an integer pointer to manipulate character string data. When type-breaking reinterpretation is necessary, document it carefully in the code. However this vulnerability cannot be completely avoided because some applications view stored data in alternative ways.
  
• 
  When using union types, prefer the use of discriminated unions. This is a type of a union where a stored value indicates which interpretation is to be placed upon the data.
  
• 
  Avoid operations that reinterpret the same stored value as representing a different type. It is easier to avoid such operations when the language clearly identifies them. For example, the name of Ada's Unchecked_Conversion function explicitly warns of the problem. A much more difficult situation occurs when pointers are used to achieve type reinterpretation. Some languages perform type-checking of pointers and place restrictions on the ability of pointers to access arbitrary locations in storage. Others permit the free use of pointers. In such cases, review the code carefully in a search for unintended reinterpretation of stored values. Therefore explicitly identify places in the source code where intended reinterpretations occur. Make 3 (or 2?) bullets.
  
• 
  Use static analysis tools in locating situations where unintended reinterpretation occurs.
  
• 
  As the presence of reinterpretation greatly complicates static analysis for other problems, consider segregating intended reinterpretation operations into distinct subprograms.
  

6.38.6 Implications for standardization

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

• 
  Because the ability to perform reinterpretation is sometimes necessary, but the need for it is rare, programming language designers might consider putting caution labels on operations that permit reinterpretation. For example, the operation in Ada that permits unconstrained reinterpretation is called Unchecked_Conversion.
  
• 
  Because of the difficulties with undiscriminated unions, programming language designers might consider offering union types that include distinct discriminants with appropriate enforcement of access to objects.
  

6.39 Deep vs. Shallow Copying [YAN]

6.39.1 Description of application vulnerability

When structures containing references as data components are copied, one must decide whether the references are to be copied (shallow copy) or, instead, the objects designated by the references are to be copied and a reference to the newly created object used as the component value of the copied structure (deep copy). Almost all languages define structure-copying operations as shallow copies, i.e., the copied structure references the same object. Deep copying is algorithmically more challenging, since no object shall be copied twice although it may be reachable by multiple paths within the graph spanned by the references. Further, deep copying may be expensive in time and memory consumption. If, however, a shallow copy is made where a deep copy was needed, serious aliasing problems can arise in the objects that are part of the graphs spanned by the copied references. Subsequent modification of such an object is visible via both the old and the new structure.

An identical problem arises when array indices are stored as component values (in lieu of pointers or references) and used to access objects in an array outside the copied data structure.

6.39.2 Cross reference

CWE: << TBD >>

JSF AV Rule 76, 77, 80

CERT C guidelines: <>

Ada Quality and Style Guide: <>

6.39.3 Mechanism of failure

Problems with shallow copying arise when values in the objects (transitively) referenced by the original or the copy are assigned to: in a deep copy, such assignments affect only the original or the copy of the graph, respectively; in a shallow copy, the value of the object is changed in both graphs, which may not have been the intention of the programmer. Consequently, the problem may manifest itself only during maintenance when, for the first time, such as assignment to a contained object is introduced, while shallow copying was originally chosen for reasons of efficiency but relying on the absence of assignments.

Knowledge of the use of shallow copying in lieu of deep copying can be exploited in attacks by causing unintended changes in data structures via the described aliasing effect.

The exposure and effects are similar to any other unintended aliasing, such as CSJ Passing Parameters and Return Values.

6.39.4 Applicable language characteristics

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

• 
  Languages that have pointers or references as part of composite data structures.
  
• 
  Languages that support arrays.
  

6.39.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Use shallow copying only where the aliasing caused is intended.
  
• 
  Use deep copying if there is any possibility that the aliasing of a shallow copy would affect the application adversely, or if in doubt.
  
• 
  Use abstractions to ensure deep copies where needed, e.g., by (re-)defining assignment operations, constructors, and other operations that copy component values.
  

6.39.6 Implications for standardization

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

• 
  Provide means to create abstractions that guarantee deep copying where needed.