CWE-754 covers products that do not check, or check incorrectly, for unusual or exceptional conditions that are not expected to occur often during day to day operation. Low memory, a denied permission, a misbehaving client, a function that returns an error: these are the conditions at stake.
It applies to every language and every kind of software. The weakness is not about exceptions as a language feature. MITRE is explicit that the entry is not exclusively about exception handling, which is only one mechanism for checking and handling unusual conditions.
How it happens
The programmer assumes certain events will never occur, or are not worth worrying about. The code works through every normal test, so the assumption survives. Then an attacker deliberately triggers the unusual condition, breaks the assumption, and the product becomes unstable, behaves wrongly, or opens a vulnerability.
The most common form is an ignored return value. A call fails, returns an error code, and the program carries on using whatever bad data came back. The record includes several examples:
- CVE-2006-4447 and CVE-2006-2916: programs did not check the return value when calling functions to drop privileges. An attacker who could make those functions fail left the user with higher privileges than expected.
- CVE-2007-3798: an unchecked return value led to an integer overflow and code execution.
- CVE-2023-49286: a chain in a web caching proxy where a function did not correctly check a return value, leading to a reachable assertion.
The privilege dropping case is worth slowing down on, because the result is the opposite of the intent. The code was written to reduce privileges, and a skipped check meant it silently did not.
// Vulnerable: if setuid fails, the process keeps running as root
setuid(1001);
run_untrusted_work();
What an attacker gains
The record lists integrity and availability. Data produced by a function call can be in a bad state on return. If the return value is not checked, that bad data may be used in later operations, possibly leading to a crash or other unintended behavior. In the worst chains, as the CVEs above show, that reaches privilege retention or code execution.
How to find it
MITRE describes two approaches.
- Automated static analysis may help with unusual conditions involving system resources and common programming idioms, such as unchecked return values. It will not find violations of business rules, and MITRE rates its coverage as moderate.
- Manual dynamic analysis means identifying error conditions unlikely in normal use and triggering them. Run the program with low memory, with insufficient privileges, with a transaction interrupted partway, or with connectivity to dependencies switched off.
The second approach is the one teams skip. A simple discipline is a fault injection pass before each release: for every external call, ask what the code does when it fails, then make it fail.
Click through it at your own pace, or open it full screen.
How to fix it
MITRE's mitigations, as steps:
- Choose language features that help. Languages with exception handling force the programmer to anticipate unusual conditions. Custom exceptions may be needed for unusual business logic conditions. Take care not to pass sensitive exceptions back to the user.
- Check the result of every function that returns a value and verify it is the value you expect. MITRE rates this high effectiveness, and notes that in concurrent code you should beware of race conditions between the check and the use.
- Catch specific exceptions, not general ones. Handle them as locally as possible so they do not travel far up the call stack, and avoid unchecked or uncaught exceptions where feasible. Also rated high.
- Keep error messages minimal. They should contain details useful to the intended audience and no one else, balanced between too cryptic and too revealing. Attackers use detailed errors to refine their attacks.
The fix for the earlier snippet is to check, and to stop when the check fails:
// Fix: fail closed if privileges cannot be dropped
if (setuid(1001) != 0) {
perror("setuid");
exit(1);
}
run_untrusted_work();
The same idea in a higher level language:
# Fix: handle the specific failure instead of ignoring it
try:
data = load_config(path)
except FileNotFoundError:
log.error("config missing at startup")
raise SystemExit(1)
Notice the program stops rather than guessing. For security relevant calls, failing closed is almost always safer than continuing in an unknown state.
Quick check
Why does an unchecked setuid call matter?
If the call fails and nobody notices, the process keeps its higher privileges while the rest of the code assumes it dropped them.
Is CWE-754 only about try and catch?
No. Exceptions are one mechanism. The weakness is any missing or wrong check for rare conditions, including return codes and resource failures.
What is a good test for this weakness?
Trigger the unusual condition on purpose: low memory, missing permissions, an interrupted transaction, or a dependency that is offline.
