CWE-703: Improper Check or Handling of Exceptional Conditions — Weakness Description, Examples & Mitigations

Description

The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.

Potential Impact

Confidentiality, Availability, Integrity

Read Application Data, DoS: Crash, Exit, or Restart, Unexpected State

Demonstrative Examples

Consider the following code segment:

Bad

char buf[10], cp_buf[10];fgets(buf, 10, stdin);strcpy(cp_buf, buf);

The programmer expects that when fgets() returns, buf will contain a null-terminated string of length 9 or less. But if an I/O error occurs, fgets() will not null-terminate buf. Furthermore, if the end of the file is reached before any characters are read, fgets() returns without writing anything to buf. In both of these situations, fgets() signals that something unusual has happened by returning NULL, but in this code, the warning will not be noticed. The lack of a null terminator in buf can result in a buffer overflow in the subsequent call to strcpy().

The following method throws three types of exceptions.

Good

public void doExchange() throws IOException, InvocationTargetException, SQLException {...}

While it might seem tidier to write

Bad

public void doExchange() throws Exception {...}

doing so hampers the caller's ability to understand and handle the exceptions that occur. Further, if a later revision of doExchange() introduces a new type of exception that should be treated differently than previous exceptions, there is no easy way to enforce this requirement.

Detection Methods

Dynamic Analysis with Manual Results Interpretation High — According to SOAR [REF-1479], the following detection techniques may be useful:
Manual Static Analysis - Source Code High — According to SOAR [REF-1479], the following detection techniques may be useful:
Automated Static Analysis - Source Code SOAR Partial — According to SOAR [REF-1479], the following detection techniques may be useful:
Architecture or Design Review High — According to SOAR [REF-1479], the following detection techniques may be useful:

Real-World CVE Examples

CVE ID	Description
[REF-1374]	Chain: JavaScript-based cryptocurrency library can fall back to the insecure Math.random() function instead of reporting a failure (CWE-392), thus reducing the entropy (CWE-332) and leading to generat
CVE-2022-22224	Chain: an operating system does not properly process malformed Open Shortest Path First (OSPF) Type/Length/Value Identifiers (TLV) (CWE-703), which can cause the process to enter an infinite loop (CWE

Taxonomy Mappings

The CERT Oracle Secure Coding Standard for Java (2011): ERR06-J — Do not throw undeclared checked exceptions

Frequently Asked Questions

What is CWE-703?

CWE-703 (Improper Check or Handling of Exceptional Conditions) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Pillar-level weakness. The product does not properly anticipate or handle exceptional conditions that rarely occur during normal operation of the product.

How can CWE-703 be exploited?

Attackers can exploit CWE-703 (Improper Check or Handling of Exceptional Conditions) to read application data, dos: crash, exit, or restart, unexpected state. This weakness is typically introduced during the Architecture and Design, Implementation, Operation phase of software development.

How do I prevent CWE-703?

Follow secure coding practices, conduct code reviews, and use automated security testing tools (SAST/DAST) to detect this weakness early in the development lifecycle.

What is the severity of CWE-703?

CWE-703 is classified as a Pillar-level weakness (Foundational abstraction). It has been observed in 2 real-world CVEs.