Unchecked Error Condition
Incomplete Base
Structure: Simple
Description
[PLANNED FOR DEPRECATION. SEE MAINTENANCE NOTES AND CONSIDER CWE-252, CWE-248, OR CWE-1069.] Ignoring exceptions and other error conditions may allow an attacker to induce unexpected behavior unnoticed.
Common Consequences 1
Scope: IntegrityOther
Impact: Varies by ContextUnexpected StateAlter Execution Logic
Detection Methods 1
Automated Static AnalysisHigh
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)Potential Mitigations 3
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.
Demonstrative Examples 1
The following code excerpt ignores a rarely-thrown exception from doExchange().
Code Example:
Bad
Java
java// 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.
References 1
The CLASP Application Security Process
Secure Software, Inc.
2005
ID: REF-18
Likelihood of Exploit
Medium
Applicable Platforms
Languages:
Not Language-Specific : Undetermined
Modes of Introduction
Implementation
Related Weaknesses
Taxonomy Mapping
- PLOVER
- 7 Pernicious Kingdoms
- CLASP
- OWASP Top Ten 2004
- CERT C Secure Coding
- CERT C Secure Coding
- CERT C Secure Coding
- CERT C Secure Coding
- CERT C Secure Coding
- SEI CERT Perl Coding Standard
- Software Fault Patterns
Notes
MaintenanceThis entry is slated for deprecation; it has multiple widespread interpretations by CWE analysts. It currently combines information from three different taxonomies, but each taxonomy is talking about a slightly different issue. CWE analysts might map to this entry based on any of these issues. 7PK has "Empty Catch Block" which has an association with empty exception block (Empty Exception Block); in this case, the exception has performed the check, but does not handle. In PLOVER there is "Unchecked Return Value" which is Unchecked Return Value, but unlike "Empty Catch Block" there isn't even a check of the issue - and "Unchecked Error Condition" implies lack of a check. For CLASP, "Uncaught Exception" (Uncaught Exception) is associated with incorrect error propagation - uncovered in CWE 3.2 and earlier, at least. There are other issues related to error handling and checks.
Other
When a programmer ignores an exception, they implicitly state that they are operating under one of two assumptions:
- This method call can never fail.
- It doesn't matter if this call fails.