Description

The software does not check the return value from a method or function, which can prevent it from detecting unexpected states and conditions.

Extended Description

Two common programmer assumptions are "this function call can never fail" and "it doesn't matter if this function call fails". If an attacker can force the function to fail or otherwise return a value that is not expected, then the subsequent program logic could lead to a vulnerability, because the software is not in a state that the programmer assumes. For example, if the program calls a function to drop privileges but does not check the return code to ensure that privileges were successfully dropped, then the program will continue to operate with the higher privileges.

Likelihood of Exploit: Low

Applicable Platforms
Language Class: All

Time Of Introduction

• Implementation

Common Consequences

Detection Methods
None

Potential Mitigations

Relationships

Demonstrative Examples   (Details)

1. Consider the following code segment: (Demonstrative Example Id DX-7)
2. It is not uncommon for Java programmers to misunderstand read() and related methods that are part of many java.io classes. Most errors and unusual events in Java result in an exception being thrown. But the stream and reader classes do not consider it 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. This behavior makes it important for programmers to examine the return value from read() and other IO methods to ensure that they receive the amount of data they expect.
3. 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)
4. 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)
5. 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)
6. 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 treat it as though it belongs to the attacker. (Demonstrative Example Id DX-9)
7. 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)
8. The following function attempts to acquire a lock in order to perform operations on a shared resource. (Demonstrative Example Id DX-24)
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.
4. CVE-2008-5183 : chain: unchecked return value can lead to NULL dereference
5. CVE-2010-0211 : chain: unchecked return value (CWE-252) leads to free of invalid, uninitialized pointer (CWE-824).

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. M. Howard D. LeBlanc .Writing Secure Code 2nd Edition. Microsoft. Section:'Chapter 20, "Checking Returns" Page 624'. Published on 2002.
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. CERT .ERR10-CPP. Check for error conditions.