Improper Check for Unusual or Exceptional ConditionsID: 754 | Date: (C)2012-05-14 (M)2022-10-10 |
Type: weakness | Status: INCOMPLETE |
Abstraction Type: Class |
Description
The software does not check or improperly checks for unusual or
exceptional conditions that are not expected to occur frequently during day to
day operation of the software.
Extended DescriptionThe 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.
Likelihood of Exploit: Medium
Applicable PlatformsLanguage Class: Language-independent
Time Of Introduction
Related Attack Patterns
Common Consequences
Scope | Technical Impact | Notes |
---|
IntegrityAvailability | DoS: crash / exit /
restartUnexpected state | The data which were produced as a result of a function call could be
in a bad state upon return. If the return value is not checked, then
this bad data may be used in operations, possibly leading to a crash or
other unintended behaviors. |
Detection Methods
Name | Description | Effectiveness | Notes |
---|
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. | Moderate | |
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. | | |
Potential Mitigations
Phase | Strategy | Description | Effectiveness | Notes |
---|
Requirements | Language Selection | 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 | | Check the results of all functions that return a value and verify that
the value is expected. | High | Checking the return value of the function will typically be
sufficient, however beware of race conditions (CWE-362) in a concurrent
environment. |
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). | High | Using specific exceptions, and ensuring that exceptions are checked,
helps programmers to anticipate and appropriately handle many unusual
events that could occur. |
Implementation | | Ensure that error messages only contain minimal details that are
useful to the intended audience, and nobody else. The messages need to
strike the balance between being too cryptic and not being cryptic
enough. They should not necessarily reveal the methods that were used to
determine the error. Such detailed information can be used to refine the
original attack to increase the chances of success.If errors must be tracked in some detail, capture them in log messages
- but consider what could occur if the log messages can be viewed by
attackers. Avoid recording highly sensitive information such as
passwords in any form. Avoid inconsistent messaging that might
accidentally tip off an attacker about internal state, such as whether a
username is valid or not.Exposing additional information to a potential attacker in the context
of an exceptional condition can help the attacker determine what attack
vectors are most likely to succeed beyond DoS. | | |
Implementation | Input Validation | Assume all input is malicious. Use an "accept known good" input
validation strategy, i.e., use a whitelist 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
related fields, and conformance to business rules. As an example of
business rule logic, "boat" may be syntactically valid because it only
contains alphanumeric characters, but it is not valid if the input is
only expected to contain colors such as "red" or "blue."Do not rely exclusively on looking for malicious or malformed inputs
(i.e., do not rely on a blacklist). A blacklist is likely to miss at
least one undesirable input, especially if the code's environment
changes. This can give attackers enough room to bypass the intended
validation. However, blacklists can be useful for detecting potential
attacks or determining which inputs are so malformed that they should be
rejected outright. | | Performing extensive input validation does not help with handling
unusual conditions, but it will minimize their occurrences and will make
it more difficult for attackers to trigger them. |
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 has a better chance of recovery. | | |
Architecture and Design | | Use system limits, which should help to prevent resource exhaustion.
However, the software should still handle low resource conditions since
they may still occur. | | |
RelationshipsSometimes, when a return value can be used to indicate an error, an
unchecked return value is a code-layer instance of a missing
application-layer check for exceptional conditions. However, return values
are not always needed to communicate exceptional conditions. For example,
expiration of resources, values passed by reference, asynchronously modified
data, sockets, etc. may indicate exceptional conditions without the use of a
return value.
Related CWE | Type | View | Chain |
---|
CWE-754 ChildOf CWE-889 | Category | CWE-888 | |
Demonstrative Examples (Details)
- Consider the following code segment: (Demonstrative Example Id DX-7)
- In the following C/C++ example the method outputStringToFile opens
a file in the local filesystem and outputs a string to the file. The input
parameters output and filename contain the string to output to the file and
the name of the file respectively.
- In the following Java example the method readFromFile uses a
FileReader object to read the contents of a file. The FileReader object is
created using the File object readFile, the readFile object is initialized
using the setInputFile method. The setInputFile method should be called
before calling the readFromFile method.
- 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. (Demonstrative Example Id DX-12)
- The following code does not check to see if memory allocation
succeeded before attempting to use the pointer returned by
malloc(). (Demonstrative Example Id DX-8)
- 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. (Demonstrative Example Id DX-10)
- The following 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 handle it as though it belongs to the
attacker. (Demonstrative Example Id DX-9)
- 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. (Demonstrative Example Id DX-11)
- This example takes an IP address from a user, verifies that it is
well formed and then looks up the hostname and copies it into a
buffer. (Demonstrative Example Id DX-1)
Observed Examples
- 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.
For more examples, refer to CVE relations in the bottom box.
White Box Definitions None
Black Box Definitions None
Taxynomy Mappings
Taxynomy | Id | Name | Fit |
---|
CERT C++ Secure Coding | MEM32-CPP | Detect and handle memory allocation errors | |
CERT C++ Secure Coding | ERR39-CPP | Guarantee exception safety | |
CERT C Secure Coding | MEM32-C | Detect and handle memory allocation errors | |
References:
- Mark Dowd John McDonald Justin Schuh .The Art of Software Security Assessment 1st Edition. Addison Wesley. Section:'Chapter 7, "Program Building Blocks" Page
341'. Published on 2006.
- Mark Dowd John McDonald Justin Schuh .The Art of Software Security Assessment 1st Edition. Addison Wesley. Section:'Chapter 1, "Exceptional Conditions," Page
22'. Published on 2006.
- Michael Howard David LeBlanc John Viega .24 Deadly Sins of Software Security. McGraw-Hill. Section:'"Sin 11: Failure to Handle Errors Correctly." Page
183'. Published on 2010.
- Frank Kim .Top 25 Series - Rank 15 - Improper Check for Unusual or
Exceptional Conditions. SANS Software Security Institute. 2010-03-15.