Baseline for Ed 2 of tr 24772

6.25 Likely Incorrect Expression [KOA]

6.25.1 Description of application vulnerability

Certain expressions are symptomatic of what is likely to be a mistake made by the programmer. The statement is not contrary to the language standard, but is unlikely to be intended. The statement may have no effect and effectively is a null statement or may introduce an unintended side-effect. A common example is the use of = in an if expression in C where the programmer meant to do an equality test using the == operator. Other easily confused operators in C are the logical operators such as && for the bitwise operator &, or vice versa. It is valid and possible that the programmer intended to do an assignment within the if expression, but due to this being a common error, a programmer doing so would be using a poor programming practice. A less likely occurrence, but still possible is the substitution of == for = in what is supposed to be an assignment statement, but which effectively becomes a null statement. These mistakes may survive testing only to manifest themselves in deployed code where they may be maliciously exploited.

6.25.2 Cross reference

CWE:

480. Use of Incorrect Operator

481. Assigning instead of Comparing

482. Comparing instead of Assigning

570. Expression is Always False

571. Expression is Always True

JSF AV Rules: 160

MISRA C 2012: 2.2, 13.3-13.6, and 14.3

MISRA C++ 2008: 0-1-9, 5-0-1, 6-2-1, and 6-5-2

CERT C guidelines: MSC02-C and MSC03-C

6.25.3 Mechanism of failure

Some of the failures are simply a case of programmer carelessness. Substitution of = in place of == in a Boolean test is easy to do and most C and C++ programmers have made this mistake at one time or another. Other instances can be the result of intricacies of the language definition that specifies what part of an expression must be evaluated. For instance, having an assignment expression in a Boolean statement is likely assuming that the complete expression will be executed in all cases. However, this is not always the case as sometimes the truth-value of the Boolean expression can be determined after only executing some portion of the expression. For instance:

if ((a == b) || (c = (d-1)))

Should (a==b) be determined to be true, then there is no need for the subexpression (c=(d-1)) to be executed and as such, the assignment (c=(d-1)) will not occur.

Embedding expressions in other expressions can yield unexpected results. Increment and decrement operators (++ and --) can also yield unexpected results when mixed into a complex expression.

Incorrectly calculated results can lead to a wide variety of erroneous program execution

6.25.4 Applicable language characteristics

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

• 
  All languages are susceptible to likely incorrect expressions.
  

6.25.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Simplify expressions.
  
• 
  Do not use assignment expressions as function parameters. Sometimes the assignment may not be executed as expected. Instead, perform the assignment before the function call.
  
• 
  Do not perform assignments within a Boolean expression. This is likely unintended, but if it is not, then move the assignment outside of the Boolean expression for clarity and robustness.
  
• 
  Use static analysis tools that detect and warn of expressions that include assignment within the expression.
  
• 
  On some rare occasions, some statements intentionally do not have side effects and do not cause control flow to change. These should be annotated through comments and made obvious that they are intentionally no-ops with a stated reason. If possible, such reliance on null statements should be avoided. In general, except for those rare instances, all statements should either have a side effect or cause control flow to change.
  

6.25.6 Implications for standardization

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

• 
  Languages should consider providing warnings for statements that are unlikely to be right such as statements without side effects. A null (no-op) statement may need to be added to the language for those rare instances where an intentional null statement is needed. Having a null statement as part of the language will reduce confusion as to why a statement with no side effects is present in the code.
  
• 
  Languages should consider not allowing assignments used as function parameters.
  
• 
  Languages should consider not allowing assignments within a Boolean expression.
  
• 
  Language definitions should avoid situations where easily confused symbols (such as = and ==, or ; and :, or != and /=) are valid in the same context. For example, = is not generally valid in an if statement in Java because it does not normally return a Boolean value.
  

6.26 Dead and Deactivated Code [XYQ]

6.26.1 Description of application vulnerability

Dead and Deactivated code is code that exists in the executable, but which can never be executed, either because there is no call path that leads to it (for example, a function that is never called), or the path is semantically infeasible (for example, its execution depends on the state of a conditional that can never be achieved).

Dead and Deactivated code may be undesirable because it may indicate the possibility of a coding error. A security issue is also possible if a “jump target” is injected. Many safety standards prohibit dead code because dead code is not traceable to a requirement.

Also covered in this vulnerability is code which is believed to be dead, but which is inadvertently executed.

Dead and Deactivated code is considered separately from the description of Unused Variable, which is provided by [YZS].

6.26.2 Cross reference

CWE:

561. Dead Code

570. Expression is Always False
571. Expression is Always True

JSF AV Rules: 127 and 186

MISRA C 2012: 2.1 and 4.4

MISRA C++ 2008: 0-1-1 to 0-1-10, 2-7-2, and 2-7-3

CERT C guidelines: MSC07-C and MSC12-C

DO-178B/C

6.26.3 Mechanism of failure

DO-178B defines Dead and Deactivated code as:

• 
  Dead code – Executable object code (or data) which cannot be executed (code) or used (data) in an operational configuration of the target computer environment and is not traceable to a system or software requirement.
  
• 
  Deactivated code – Executable object code (or data) which by design is either (a) not intended to be executed (code) or used (data), for example, a part of a previously developed software component, or (b) is only executed (code) or used (data) in certain configurations of the target computer environment, for example, code that is enabled by a hardware pin selection or software programmed options.
  

Dead code is code that exists in an application, but which can never be executed, either because there is no call path to the code (for example, a function that is never called) or because the execution path to the code is semantically infeasible, as in

integer i = 0;

if (i == 0)

then fun_a();

else fun_b();

fun_b() is Dead code, as only fun_a() can ever be executed.

Compilers that optimize sometimes generate and then remove dead code, including code placed there by the programmer. The deadness of code can also depend on the linking of separately compiled modules.

The presence of dead code is not in itself an error. There may also be legitimate reasons for its presence, for example:

• 
  Defensive code, only executed as the result of a hardware failure.
  
• 
  Code that is part of a library not required in the program in question.
  
• 
  Diagnostic code not executed in the operational environment.
  
• 
  Code that is temporarily deactivated but may be needed soon. This may occur as a way to make sure the code is still accepted by the language translator to reduce opportunities for errors when it is reactivated.
  
• 
  Code that is made available so that it can be executed manually via a debugger.
  

Such code may be referred to as deactivated. That is, dead code that is there by intent.

There is a secondary consideration for dead code in languages that permit overloading of functions and other constructs that use complex name resolution strategies. The developer may believe that some code is not going to be used (deactivated), but its existence in the program means that it appears in the namespace, and may be selected as the best match for some use that was intended to be of an overloading function. That is, although the developer believes it is never going to be used, in practice it may be used in preference to the intended function.

However, it may be the case that, because of some other error, the code is rendered unreachable. Therefore, any dead code should be reviewed and documented.

Be aware that some defensive code, such as that created to catch hardware error, may be optimized away by the compiler. Use of optimization fences such as volatile accesses (consult language and compiler manuals) may help.

6.26.4 Applicable language characteristics

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

• 
  Languages that allow code to exist in a program or executable, which can never be executed.
  

6.26.5 Avoiding the vulnerability or mitigating its effects

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

• 
  Remove dead code from an application unless its presence serves a documented purpose.
  
• 
  When a developer identifies code that is dead because a conditional consistently evaluates to the same value, this could be indicative of an earlier bug or it could be indicative of inadequate path coverage in the test regimen. Additional investigation may be needed to ascertain why the same value is occurring.
  
• 
  Identify any dead code in the application, and provide a justification as to why it is there.
  
• 
  Ensure that any code that was expected to be unused is documented as dead code.
  
• 
  For code that appears to be dead code but is in reality accessible only by asynchronous events or error handlers, or present for debugging purposes, prevent the optimizations that remove the code in question. Examples include the judicious use of volatile accesses, pragmas, or compiler switches.
  
• 
  Apply standard branch coverage measurement tools and ensure by 100% coverage that all branches are neither dead nor deactivated.
  
• 
  Use static analysis tools to identify unreachable code.
  

6.26.6 Implications for standardization

[None]