Unchecked Return ValueID: 252 | Date: (C)2012-05-14 (M)2022-10-10 |
Type: weakness | Status: DRAFT |
Abstraction Type: Base |
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 DescriptionTwo 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 PlatformsLanguage Class: All
Time Of Introduction
Common Consequences
Scope | Technical Impact | Notes |
---|
AvailabilityIntegrity | Unexpected stateDoS: crash / exit /
restart | An unexpected return value could place the system in a state that
could lead to a crash or other unintended behaviors. |
Detection MethodsNone
Potential Mitigations
Phase | Strategy | Description | Effectiveness | Notes |
---|
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 | | Ensure that you account for all possible return values from the
function. | | |
Implementation | | When designing a function, make sure you return a value or throw an
exception in case of an error. | | |
Relationships
Related CWE | Type | View | Chain |
---|
CWE-252 ChildOf CWE-889 | Category | CWE-888 | |
Demonstrative Examples (Details)
- Consider the following code segment: (Demonstrative Example Id DX-7)
- 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.
- 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 treat 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)
- The following function attempts to acquire a lock in order to
perform operations on a shared resource. (Demonstrative Example Id DX-24)
- 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.
- CVE-2008-5183 : chain: unchecked return value can lead to NULL dereference
- CVE-2010-0211 : chain: unchecked return value (CWE-252) leads to free of invalid, uninitialized pointer (CWE-824).
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 |
---|
7 Pernicious Kingdoms | | Unchecked Return Value | |
CLASP | | Ignored function return value | |
OWASP Top Ten 2004 | A7 | Improper Error Handling | CWE_More_Specific |
CERT C Secure Coding | MEM32-C | Detect and handle memory allocation errors | |
CERT Java Secure Coding | EXP00-J | Do not ignore values returned by methods | |
CERT C++ Secure Coding | MEM32-CPP | 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.
- M. Howard D. LeBlanc .Writing Secure Code 2nd Edition. Microsoft. Section:'Chapter 20, "Checking Returns" Page 624'. Published on 2002.
- 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.
- CERT .ERR10-CPP. Check for error conditions.