Ignoring exceptions and other error conditions may allow an attacker to induce unexpectedbehavior unnoticed.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
All
Common Consequences
Scope
Effect
Integrity
Other
Technical Impact: Varies by context; Unexpected state; Alter execution
logic
Likelihood of Exploit
Medium
Demonstrative Examples
Example 1
The following code excerpt ignores a rarely-thrown exception from
doExchange().
(Bad Code)
Example
Language: Java
try {
doExchange();
}
catch (RareException e) {
// this can never happen
}
If a RareException were to ever be thrown, the program would continue
to execute as though nothing unusual had occurred. The program records
no evidence indicating the special situation, potentially frustrating
any later attempt to explain the program's behavior.
Potential Mitigations
Phase: Requirements
The choice between a language which has named or unnamed exceptions
needs to be done. While unnamed exceptions exacerbate the chance of not
properly dealing with an exception, named exceptions suffer from the up
call version of the weak base class problem.
Phase: Requirements
A language can be used which requires, at compile time, to catch all
serious exceptions. However, one must make sure to use the most current
version of the API as new exceptions could be added.
Phase: Implementation
Catch all relevant exceptions. This is the recommended solution.
Ensure that all exceptions are handled in such a way that you can be
sure of the state of your system at any given moment.
Other Notes
Just about every serious attack on a software system begins with the
violation of a programmer's assumptions. After the attack, the programmer's
assumptions seem flimsy and poorly founded, but before an attack many
programmers would defend their assumptions well past the end of their lunch
break. Two dubious assumptions that are easy to spot in code are "this
method call can never fail" and "it doesn't matter if this call fails". When
a programmer ignores an exception, they implicitly state that they are
operating under one of these assumptions.
Adopt and implement a consistent and comprehensive
error-handling policy
CERT C Secure Coding
FIO04-C
Detect and handle input and output errors
CERT C Secure Coding
FIO33-C
Detect and handle input output errors resulting in undefined
behavior
CERT C++ Secure Coding
MEM32-CPP
Detect and handle memory allocation errors
CERT C++ Secure Coding
FIO04-CPP
Detect and handle input and output errors
CERT C++ Secure Coding
FIO33-CPP
Detect and handle input output errors resulting in undefined
behavior
CERT C++ Secure Coding
ERR00-CPP
Adopt and implement a consistent and comprehensive
error-handling policy
CERT C++ Secure Coding
ERR10-CPP
Check for error conditions
White Box Definitions
A weakness where code path has:
1. start statement that changes a state of the system resource
2. end statement that accesses the system resource, where the changed
and the assumed state of the system resource are not equal.
3. the state of the resource is not compatible with the type of access
being performed by the end statement
Maintenance Notes
This entry needs significant modification. It currently combines
information from three different taxonomies, but each taxonomy is talking
about a slightly different issue.
Description
