CWE-754: Improper Check for Unusual or Exceptional Conditions

Description

The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

The programmer may assume that certain events or conditions will never occur or do not need to be worried about, such as low memory conditions, lack of access to resources due to restrictive permissions, or misbehaving clients or components. However, attackers may intentionally trigger these unusual conditions, thus violating the programmer's assumptions, possibly introducing instability, incorrect behavior, or a vulnerability. Note that this entry is not exclusively about the use of exceptions and exception handling, which are mechanisms for both checking and handling unusual or unexpected conditions.

Potential Impact

Integrity, Availability

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 code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().

Bad

buf = (char*) malloc(req_size);strncpy(buf, xfer, req_size);

The traditional defense of this coding error is: "If my program runs out of memory, it will fail. It doesn't matter whether I handle the error or simply allow the program to die with a segmentation fault when it tries to dereference the null pointer." This argument ignores three important considerations:

The following examples read a file into a byte array.

Bad

char[] byteArray = new char[1024];for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {String userName = (String) i.Current();String pFileName = PFILE_ROOT + "/" + userName;StreamReader sr = new StreamReader(pFileName);sr.Read(byteArray,0,1024);//the file is always 1k bytessr.Close();processPFile(userName, byteArray);}

Bad

FileInputStream fis;byte[] byteArray = new byte[1024];for (Iterator i=users.iterator(); i.hasNext();) {
                        String userName = (String) i.next();String pFileName = PFILE_ROOT + "/" + userName;FileInputStream fis = new FileInputStream(pFileName);fis.read(byteArray); // the file is always 1k bytesfis.close();processPFile(userName, byteArray);

The code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always 1 kilobyte in size and therefore ignores the return value from Read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and treat it as though it belongs to the attacker.

The following code does not check to see if the string returned by getParameter() is null before calling the member function compareTo(), potentially causing a NULL dereference.

Bad

String itemName = request.getParameter(ITEM_NAME);if (itemName.compareTo(IMPORTANT_ITEM) == 0) {...}...

The following code does not check to see if the string returned by the Item property is null before calling the member function Equals(), potentially causing a NULL dereference.

Bad

String itemName = request.Item(ITEM_NAME);if (itemName.Equals(IMPORTANT_ITEM)) {...}...

The traditional defense of this coding error is: "I know the requested value will always exist because.... If it does not exist, the program cannot perform the desired behavior so it doesn't matter whether I handle the error or simply allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

Mitigations & Prevention

Requirements

Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Choose languages with features such as exception handling that force the programmer to anticipate unusual conditions that may generate exceptions. Custom exceptions may need to be developed to handle unusual business-logic conditions. Be careful not to pass sensitive exceptions back to the user (CWE-209, CWE-248).

Implementation High

Check the results of all functions that return a value and verify that the value is expected.

Implementation High

If using exception handling, catch and throw specific exceptions instead of overly-general exceptions (CWE-396, CWE-397). Catch and handle exceptions as locally as possible so that exceptions do not propagate too far up the call stack (CWE-705). Avoid unchecked or uncaught exceptions where feasible (CWE-248).

Implementation

Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If

Implementation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across relat

Architecture and DesignImplementation

If the program must fail, ensure that it fails gracefully (fails closed). There may be a temptation to simply let the program fail poorly in cases such as low memory conditions, but an attacker may be able to assert control before the software has fully exited. Alternately, an uncontrolled failure could cause cascading problems with other downstream components; for example, the program could send a signal to a downstream process so the process immediately knows that a problem has occurred and ha

Architecture and Design

Use system limits, which should help to prevent resource exhaustion. However, the product should still handle low resource conditions since they may still occur.

Detection Methods

Automated Static Analysis Moderate — Automated static analysis may be useful for detecting unusual conditions involving system resources or common programming idioms, but not for violations of business rules.
Manual Dynamic Analysis — Identify error conditions that are not likely to occur during normal usage and trigger them. For example, run the program under low memory conditions, run with insufficient privileges or permissions, interrupt a transaction before it is completed, or disable connectivity to basic network services su

Real-World CVE Examples

CVE ID	Description
CVE-2023-49286	Chain: function in web caching proxy does not correctly check a return value (CWE-253) leading to a reachable assertion (CWE-617)
CVE-2007-3798	Unchecked return value leads to resultant integer overflow and code execution.
CVE-2006-4447	Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.
CVE-2006-2916	Program does not check return value when invoking functions to drop privileges, which could leave users with higher privileges than expected by forcing those functions to fail.

Taxonomy Mappings

SEI CERT Perl Coding Standard: EXP31-PL — Do not suppress or ignore exceptions
ISA/IEC 62443: Part 4-2 — Req CR 3.5
ISA/IEC 62443: Part 4-2 — Req CR 3.7

Frequently Asked Questions

What is CWE-754?

CWE-754 (Improper Check for Unusual or Exceptional Conditions) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Class-level weakness. The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.

How can CWE-754 be exploited?

Attackers can exploit CWE-754 (Improper Check for Unusual or Exceptional Conditions) to dos: crash, exit, or restart, unexpected state. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-754?

Key mitigations include: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Choose languages with features such as exception handling

What is the severity of CWE-754?

CWE-754 is classified as a Class-level weakness (High abstraction). It has been observed in 4 real-world CVEs.