Baseline for Ed 2 of tr 24772

6.21 Namespace Issues [BJL]

6.21.1 Description of Application Vulnerability

If a language provides separate, non-hierarchical namespaces, a user-controlled ordering of namespaces, and a means to make names declared in these namespaces directly visible to an application, the potential of unintentional and possible disastrous change in application behaviour can arise, when names are added to a namespace during maintenance.

Namespaces include constructs like packages, modules, libraries, classes or any other means of grouping declarations for import into other program units.

6.21.2 Cross references

MISRA C++ 2008: 7-3-1, 7-3-3, 7-3-5, 14-5-1, and 16-0-2

6.21.3 Mechanism of Failure

The failure is best illustrated by an example. Namespace N1 provides the name A, but not B. Namespace N2 provides the name B but not A. The application wishes to use A from N1 and B from N2. At this point, there are no obvious issues. The application chooses (or needs) to import both namespaces to obtain names for direct usage, for an example.

Use N1, N2; – presumed to make all names in N1 and N2 directly visible in the scope of intended use

… X := A + B;

The semantics of the above example are intuitive and unambiguous.

Later, during maintenance, the name B is added to N1. The change to the namespace usually implies a recompilation of dependent units. At this point, two declarations of B are applicable for the use of B in the above example.

Some languages try to disambiguate the above situation by stating preference rules in case of such ambiguity among names provided by different name spaces. If, in the above example, N1 is preferred over N2, the meaning of the use of B changes silently, presuming that no typing error arises. Consequently the semantics of the program change silently and assuredly unintentionally, since the implementer of N1 cannot assume that all users of N1 would prefer to take any declaration of B from N1 rather than its previous namespace.

It does not matter what the preference rules actually are, as long as the namespaces are mutable. The above example is easily extended by adding A to N2 to show a symmetric error situation for a different precedence rule.

If a language supports overloading of subprograms, the notion of “same name” used in the above example is extended to mean not only the same name, but also the same signature of the subprogram. For vulnerabilities associated with overloading and overriding, see 6.20 Identifier Name Reuse [YOW]. In the context of namespaces, however, adding signature matching to the name binding process, merely extends the described problem from simple names to full signatures, but does not alter the mechanism or quality of the described vulnerability. In particular, overloading does not introduce more ambiguity for binding to declarations in different name spaces.

This vulnerability not only creates unintentional errors, but it also can be exploited maliciously, if the source of the application and of the namespaces is known to the aggressor and one of the namespaces is mutable by the attacker.

6.21.4 Applicable Language Characteristics

The vulnerability is applicable to languages with the following characteristics:

• 
  Languages that support non-hierarchical separate name-spaces, have means to import all names of a namespace “wholesale” for direct use, and have preference rules to choose among multiple imported direct homographs. All three conditions need to be satisfied for the vulnerability to arise.
  

6.21.5 Avoiding the Vulnerability or Mitigating its Effects

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

• 
  Avoid “wholesale” import directives, i.e. directives that give all imported names the same visibility level as each other and/or the same visibility level as local names (provided that the language offers the respective capabilities);
  
• 
  Use only selective “single name” import directives or using fully qualified names (provided that the language offers the respective capabilities)
  

6.21.6 Implications for Standardization

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

• 
  Languages should not have preference rules among mutable namespaces. Ambiguities should be invalid and avoidable by the user, for example, by using names qualified by their originating namespace.
  

6.22 Initialization of Variables [LAV]

6.22.1 Description of application vulnerability

Reading a variable that has not been assigned a value appropriate to its type can cause unpredictable execution in the block that uses the value of that variable, and has the potential to export bad values to callers, or to cause out-of-bounds memory accesses.

Uninitialized variable usage is frequently not detected until after testing and often when the code in question is delivered and in use, because happenstance will provide variables with adequate values (such as default data settings or accidental left-over values) until some other change exposes the defect.

Variables that are declared during module construction (by a class constructor, instantiation, or elaboration) may have alternate paths that can read values before they are set. This can happen in straight sequential code but is more prevalent when concurrency or co-routines are present, with the same impacts described above.

Another vulnerability occurs when compound objects are initialized incompletely, as can happen when objects are incrementally built, or fields are added under maintenance.

When possible and supported by the language, whole-structure initialization is preferable to field-by-field initialization statements, and named association is preferable to positional, as it facilitates human review and is less susceptible to error injection under maintenance. For classes, the declaration and initialization may occur in separate modules. In such cases it must be possible to show that every field that needs an initial value receives that value, and to document ones that do not require initial values.

6.22.2 Cross reference

CWE:

457. Use of Uninitialized Variable

JSF AV Rules: 71, 143, and 147

MISRA C 2012: 9.1, 9.2, and 9.3

MISRA C++ 2008: 8-5-1

CERT C guidelines: DCL14-C and EXP33-C

Ada Quality and Style Guide: 5.9.6

6.22.3 Mechanism of failure

Uninitialized objects may have invalid values, valid but wrong values, or valid and dangerous values. Wrong values could cause unbounded branches in conditionals or unbounded loop executions, or could simply cause wrong calculations and results.

There is a special case of pointers or access types. When such a type contains null values, a bound violation and hardware exception can result. When such a type contains plausible but meaningless values, random data reads and writes can collect erroneous data or can destroy data that is in use by another part of the program; when such a type is an access to a subprogram with a plausible (but wrong) value, then either a bad instruction trap may occur or a transfer to an unknown code fragment can occur. All of these scenarios can result in undefined behaviour.

Uninitialized variables are difficult to identify and use for attackers, but can be arbitrarily dangerous in safety situations.

The general problem of showing that all program objects are initialized is intractable;

6.22.4 Applicable language characteristics

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

• 
  Languages that permit variables to be read before they are assigned.
  

6.22.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Carefully structure programs to show that all variables are set before first read on every path throughout each subprogram.
  
• 
  When an object is visible from multiple modules, identify a module that must set the value before reads can occur from any other module that can access the object, and ensure that this module is executed first.
  
• 
  When concurrency, interrupts and co-routines are present, identify where early initialization occurs and show that the correct order is set via program structure, not by timing, OS precedence, or chance.
  
• 
  Initialize each object at elaboration time, or immediately after subprogram execution commences and before any branches.
  
• 
  If the subprogram must commence with conditional statements, show that every variable declared and not initialized earlier is initialized on each branch.
  
• 
  Ensure that the initial object value is a sensible value for the logic of the program. The so-called "junk initialization" (such as, for example, setting every variable to zero) prevents the use of tools to detect otherwise uninitialized variables.
  
• 
  Define or reserve fields or portions of the object to only be set when fully initialized. Consider, however, that this approach has the effect of setting the variable to possibly mistaken values while defeating the use of static analysis to find the uninitialized variables.
  
• 
  Use static analysis tools to show that all objects are set before use. As the general problem is intractable, keep initialization algorithms simple so that they can be analyzed.
  
• 
  When declaring and initializing the object together, if the language does not require the compiler to statically verify that the declarative structure and the initialization structure match, use static analysis tools to help detect any mismatches.
  
• 
  When setting compound objects, if the language provides mechanisms to set all components together, use those in preference to a sequence of initializations as this facilitates coverage analysis; otherwise use tools that perform such coverage analysis and document the initialization. Do not perform partial initializations unless there is no choice, and document any deviations from full initialization.
  
• 
  Where default assignments of multiple components are performed, explicit declaration of the component names and/or ranges helps static analysis and identification of component changes during maintenance.
  
• 
  Use named assignments in preference to positional assignment where the language has named assignments that can be used to build reviewable assignment structures that can be analyzed by the language processor for completeness. Use comments and secondary tools to help show correct assignment where the language only supports positional assignment notation.
  

6.22.6 Implications for standardization

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

• 
  Some languages have ways to determine if modules and regions are elaborated and initialized and to raise exceptions if this does not occur. Languages that do not, could consider adding such capabilities.
  
• 
  Languages could consider setting aside fields in all objects to identify if initialization has occurred, especially for security and safety domains.
  
• 
  Languages that do not support whole-object initialization, could consider adding this capability.