CWE-391: Unchecked Error Condition

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.

Potential Impact

Integrity, Other

Varies by Context, Unexpected State, Alter Execution Logic

Demonstrative Examples

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

Bad

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.

Mitigations & Prevention

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.

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.

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.

Detection Methods

Automated Static Analysis High — 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 sea

Taxonomy Mappings

PLOVER: — Unchecked Return Value
7 Pernicious Kingdoms: — Empty Catch Block
CLASP: — Uncaught exception
OWASP Top Ten 2004: A7 — Improper Error Handling
CERT C Secure Coding: ERR00-C — Adopt and implement a consistent and comprehensive error-handling policy
CERT C Secure Coding: ERR33-C — Detect and handle standard library errors
CERT C Secure Coding: ERR34-C — Detect errors when converting a string to a number
CERT C Secure Coding: FLP32-C — Prevent or detect domain and range errors in math functions
CERT C Secure Coding: POS54-C — Detect and handle POSIX library errors
SEI CERT Perl Coding Standard: EXP31-PL — Do not suppress or ignore exceptions
Software Fault Patterns: SFP4 — Unchecked Status Condition

Frequently Asked Questions

What is CWE-391?

CWE-391 (Unchecked Error Condition) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. [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 unnotice...

How can CWE-391 be exploited?

Attackers can exploit CWE-391 (Unchecked Error Condition) to varies by context, unexpected state, alter execution logic. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-391?

Key mitigations include: 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

What is the severity of CWE-391?

CWE-391 is classified as a Base-level weakness (Medium abstraction). Its actual severity depends on the specific context and how the weakness manifests in your application.