Baseline for Ed 2 of tr 24772

6.43 Violations of the Liskov Liskov Substitution Principle or the Contract Model [BLP]

6.43.1 Description of application vulnerability

Object orientation typically allows polymorphic variables containing values of subclasses of the declared class of the variable. Methods of the declared class of a receiving object can be invoked and the caller has the right to expect that the semantics of the interface called upon are observed regardless of the precise nature of the value of the receiving object. Similarly, the existence of accessed components of the declared class needs to be ensured. Instances of subclasses thus need to be both technically and logically specialized instances of the parent class. This is the basis of the Liskov principle.

The Liskov Principle states that an instance of a subclass is always an instance of the superclass as well if one ignores the added specializations. It implies that inheritance is used only if there is a logical “is-a”-relationship between the subclass and the superclass. Moreover, preconditions of methods can at most be weakened and never strengthened as they are redefined for a subclass. Inversely, postconditions can at most be strengthened and never be weakened by such a redefinition. The caller of an interface needs to guarantee only the preconditions of the interface and is allowed to rely on its postconditions. The rules stated make sure of this property which is also known as the Contract Model.

Violations of the Liskov Principle or the Contract Model can result in system malfunctions as additional preconditions of redefinitions or promised postconditions of interfaces are not met.

An alternative inheritance semantics is that of “has-a”-relationships, usually appearing in programs in languages with multiple inheritance, where the paradigm is sometimes referred to as a “mix-in”. It is in stark conflict with the Liskow Principle: A polymorphic variable motor of class engine should not be able to hold a car, merely because the subclass car was created by a mix-in of the class engine to the class vehicle.

The principles stated above apply to implicit as well as explicit preconditions and postconditions. Explicit conditions permit formal reasoning tools to be applied.

6.43.2 Cross reference

CWE: << TBD >>

JSF AV Rules: 89, 91, 92, 93

CERT C++ guidelines:

Ada Quality and Style Guide: <>

6.43.3 Mechanism of failure

When a client calls the method of a class which redispatches to the implementation of a subclass with a strengthened precondition, the client has mechanism to know about the added preconditions to be satisfied. Hence the call may fail on a violated precondition. Similarly, if the called implementation has a weaker postcondition, the postcondition asserted to the client might not be satisfied. As a consequence, the client may fail. Failing to meet preconditions or to guarantee postconditions is bound to cause exceptions or system failures. The specific scenarios are extensive and range from faults that happen to be handled by the system to complete loss of security and safety.

Using visible inheritance to implement a “has-a”-relationships deteriorates class design and thereby may be the cause of consequential errors. There is no immediate failure mode, however.

6.43.4 Applicable language characteristics

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

• 
  Languages that have polymorphic variables, particularly object-oriented languages.
  
• 
  Languages that provide inheritance among classes.
  

6.43.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Obey all preconditions and postconditions of each method, whether they are specified in the language or not.
  
• 
  Prohibit the strengthening of preconditions (specified or not) by redefinitions of methods.
  
• 
  Prohibit the weakening of postconditions (specified or not) by redefinitions of methods.
  
• 
  Prohibit the use of visible inheritance for “has-a” relationships.
  
• 
  Use components of the respective class for “has-a”-relationships.
  

6.43.6 Implications for standardization

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

• 
  Provide language mechanisms to formally specify preconditions and postconditions.
  
• 
  
  

6.44 Redispatching [PPH]

6.44.1 Description of application vulnerability

When very similar functionality is provided by methods or interfaces with varying parameter structures, a frequently found implementation strategy is to designate one of them as the “work horse” and have all others call on it to perform the (common) work. A prime example are constructor or initialization methods where different sets of initial values for certain components are provided and the remaining components are set to default values.

When the semantics of inner calls of dispatching methods ask for dispatching in turn, the call is said to be “redispatching”. In this case, the following scenario can evolve: In class C, the implementation of method A dispatches to method B, the work horse. In a derived class CD, the implementation of B needs to be changed. The programmer finds the signature of the inherited method A matching his needs and calls A as part of the redefinition of B. The outcome of a previously correct dispatching call on B in C for a polymorphic variable of class C holding a reference to an object of class CD now causes infinite recursion between the redefined method B and the inherited method A of class CD.

This vulnerability is not restricted to the example above, but can happen whenever the design calls for multiple services converging to a single implementation.

6.44.2 Cross reference

CWE: << TBD >>AI – Larry, check

JSF AV Rules: (none)

MISRA C++: (none)

CERT C++ guidelines: <>AI – Larry, check

Ada Quality and Style Guide: (none)

6.44.3 Mechanism of failure

The mechanism is the intrinsic call semantics of the language. If it demands dispatching for nested method calls, the failure scenario is guaranteed. While the example above is tractable, the infinite recursion can involve multiple objects along a reference chain and, thus, it becomes quickly undecidable whether such a situation exists or not. Even for simple cases, avoidance requires knowledge about the implementation of all called methods inherited from superclasses and needs to apply this knowledge transitively. Such a requirement is diametrically opposed to fundamental software engineering axioms.

It has been shown that released libraries have contained many instances of infinite recursions.

Malicious exploit of the vulnerability adds a subclass that contains this infinite recursion conditionally on some trigger value. The recursion can be sufficiently obscured so that no analysis tool or reviewer can detect it with any certainty. The system can then be caused to fault with a stack overflow anytime this trigger is used. The vulnerability can thus be used for Denial-of-Service attacks.

6.44.4 Applicable language characteristics

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

• 
  Languages that demand or allow dispatching for calls within dispatching operations.
  

6.44.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Enforce a principle that, even across class hierarchies, converging services use a single implementation.(Erhard to consider clearer wording (with Patrice)). This likely will replace the two following ones
  
• 
  Agree on and document a redispatch hierarchy within groups of methods, such as initializers or constructors, and use it consistently throughout the class hierarchy.
  
• 
  Avoid dispatching calls in methods where possible. See upcast consequences in subclause [BKK].
  

6.44.6 Implications for standardization

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

• 
  Find a solution to the problem.