Ignoring exceptions and other error conditions may allow an
attacker to induce unexpected behavior unnoticed.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
All
Likelihood of Exploit
Medium
Demonstrative Examples
Example 1
The following code excerpt ignores a rarely-thrown exception from
doExchange().
(Bad Code)
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
Description
Requirements Specification: 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.
Requirements Specification: 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.
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
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.
Content History
Submissions
Submission Date
Submitter
Organization
Source
PLOVER
Externally Mined
Modifications
Modification Date
Modifier
Organization
Source
2008-07-01
Eric Dalci
Cigital
External
updated Time of Introduction
2008-08-01
KDM Analytics
External
added/updated white box definitions
2008-08-15
Veracode
External
Suggested OWASP Top Ten 2004
mapping
2008-09-08
CWE Content Team
MITRE
Internal
updated Maintenance Notes, Relationships, Other Notes,
Taxonomy Mappings
Description
