CWE-754: Improper Check for Unusual or Exceptional… | Glexia

Causes

• Consider the following code segment: 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(). 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. 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. 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.,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.
• The following code shows a system property that is set to null and later dereferenced by a programmer who mistakenly assumes it will always be defined. 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.
• The following VB.NET code does not check to make sure that it has read 50 bytes from myfile.txt. This can cause DoDangerousOperation() to operate on an unexpected value. In .NET, it is not uncommon for programmers to misunderstand Read() and related methods that are part of many System.IO classes. The stream and reader classes do not consider it to be unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested.

Remediation

• Requirements:
• Implementation: Check the results of all functions that return a value and verify that the value is expected.
• Implementation: 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:
• Architecture and Design,Implementation: 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 has a better chance of recovery.
• 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

• Automated Static Analysis: 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 such as DNS. Monitor the software for any unexpected behavior. If you trigger an unhandled exception or similar error that was discovered and handled by the application's environment, it may still indicate unexpected conditions that were not handled by the application itself.

Related CWEs

• CWE-252: Unchecked Return Value
• CWE-252: Unchecked Return Value
• CWE-253: Incorrect Check of Function Return Value
• CWE-273: Improper Check for Dropped Privileges
• CWE-273: Improper Check for Dropped Privileges
• CWE-354: Improper Validation of Integrity Check Value
• CWE-391: Unchecked Error Condition
• CWE-394: Unexpected Status Code or Return Value
• CWE-476: NULL Pointer Dereference
• CWE-476: NULL Pointer Dereference
• CWE-416: Use After Free
• CWE-703: Improper Check or Handling of Exceptional Conditions

Related CVEs

Related CVE mappings appear after CVE records are cross-indexed.

ATT&CK Relevance

ATT&CK relevance is shown only when reviewed or responsibly inferred.