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 Description

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.

Likelihood of Exploit: Medium

Applicable Platforms
Language Class: Language-independent

Time Of Introduction

• Implementation

Related Attack Patterns

• CAPEC-54

Common Consequences

Detection Methods

Potential Mitigations

Relationships
Sometimes, 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.

Demonstrative Examples   (Details)

1. Consider the following code segment: (Demonstrative Example Id DX-7)
2. 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.
3. 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.
4. 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)
5. 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)
6. 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)
7. 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)
8. 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)
9. 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

1. CVE-2007-3798 : Unchecked return value leads to resultant integer overflow and code execution.
2. 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.
3. 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.

White Box Definitions
None

Black Box Definitions
None

Taxynomy Mappings

References:

1. 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.
2. 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.
3. 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.
4. Frank Kim .Top 25 Series - Rank 15 - Improper Check for Unusual or Exceptional Conditions. SANS Software Security Institute. 2010-03-15.