CWE
Home > CWE List > CWE- Individual Dictionary Definition (1.0.1)  
Search by ID:

CWE-391: Unchecked Error Condition

Individual Definition in a New Window
Unchecked Error Condition
Status: Incomplete
Weakness ID: 391 (Weakness Base)
Description
Summary

Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.

Likelihood of Exploit

Medium

Potential Mitigations

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.

Demonstrative Examples

The following code excerpt ignores a rarely-thrown exception from doExchange().

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.

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.

Relationships
NatureTypeIDNameView(s) this relationship pertains toView(s)
ChildOfWeakness ClassWeakness ClassWeakness Class703Failure to Handle Exceptional Conditions
Research Concepts (primary)1000
ChildOfCategoryCategory389Error Conditions, Return Values, Status Codes
Development Concepts (primary)699
ChildOfCategoryCategory728OWASP Top Ten 2004 Category A7 - Improper Error Handling
Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOfCategoryCategory388Error Handling
Seven Pernicious Kingdoms (primary)700
MemberOfViewView630Weaknesses Examined by SAMATE
Weaknesses Examined by SAMATE (primary)630
Taxonomy Mappings
Mapped Taxonomy NameNode IDFitMapped Node Name
PLOVER  Unchecked Return Value
7 Pernicious Kingdoms  Empty Catch Block
CLASP  Uncaught exception
OWASP Top Ten 2004A7CWE More SpecificImproper Error Handling
Applicable Platforms
Languages
All
Time of Introduction
* Architecture and Design
* Implementation
White Box Definitions

A weakness where code path has:

1. start statement that changes a state of a system resource

2. end statement that accesses the system resource, where the changed and the assumed state of the system resource are not equal.

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
PLOVER. (Externally Mined)
Modifications
Eric Dalci. Cigital. 2008-07-01. (External)
updated Time_of_Introduction
KDM Analytics. 2008-08-01. (External)
added/updated white box definitions
Veracode. 2008-08-15. (External)
Suggested OWASP Top Ten 2004 mapping
CWE Content Team. MITRE. 2008-09-08. (Internal)
updated Maintenance_Notes, Relationships, Other_Notes, Taxonomy_Mappings
Page Last Updated: October 16, 2008