CWE 252

Unchecked Return Value

Weakness ID: 252 (Weakness Base)

Status: Draft

Description

Description Summary

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.

Time of Introduction

Implementation

Applicable Platforms

Languages

All

Common Consequences

Scope	Effect
Integrity	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 and lead to a crash or other unintended behaviors.

Likelihood of Exploit

Low

Demonstrative Examples

Example 1

Consider the following code segment:

(Bad Code)

Example Language: C

char buf[10], cp_buf[10];

fgets(buf, 10, stdin);

strcpy(cp_buf, buf);

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().

Example 2

The following code does not check to see if memory allocation succeeded before attempting to use the pointer returned by malloc().

(Bad Code)

Example Language: C

buf = (char*) malloc(req_size);

strncpy(buf, xfer, req_size);

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: - Depending upon the type and size of the application, it may be possible to free memory that is being used elsewhere so that execution can continue. - It is impossible for the program to perform a graceful exit if required. If the program is performing an atomic operation, it can leave the system in an inconsistent state. - The programmer has lost the opportunity to record diagnostic information. Did the call to malloc() fail because req_size was too large or because there were too many requests being handled at the same time? Or was it caused by a memory leak that has built up over time? Without handling the error, there is no way to know.

Example 3

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.

(Bad Code)

Example Language: Java

char[] byteArray = new char[1024];

for (IEnumerator i=users.GetEnumerator(); i.MoveNext() ;i.Current()) {

String userName = (String) i.Current();

String pFileName = PFILE_ROOT + "/" + userName;

StreamReader sr = new StreamReader(pFileName);

sr.Read(byteArray,0,1024);//the file is always 1k bytes

sr.Close();

processPFile(userName, byteArray);

}

(Bad Code)

Example Language: Java

FileInputStream fis;

byte[] byteArray = new byte[1024];

for (Iterator i=users.iterator(); i.hasNext();) {

String userName = (String) i.next();

String pFileName = PFILE_ROOT + "/" + userName;

FileInputStream fis = new FileInputStream(pFileName);

fis.read(byteArray); // the file is always 1k bytes

fis.close();

processPFile(userName, byteArray);

Example 4

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.

(Bad Code)

Example Language: Java

String itemName = request.getParameter(ITEM_NAME);

if (itemName.compareTo(IMPORTANT_ITEM)) {

...

}

...

The following code does not check to see if the string returned by theItem property is null before calling the member function Equals(), potentially causing a NULL dereference. string itemName = request.Item(ITEM_NAME);

(Bad Code)

if (itemName.Equals(IMPORTANT_ITEM)) {

...

}

...

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.

Example 5

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.

(Bad Code)

System.clearProperty("os.name");

...

String os = System.getProperty("os.name");

if (os.equalsIgnoreCase("Windows 95")) System.out.println("Not supported");

Example 6

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.

(Bad Code)

Dim MyFile As New FileStream("myfile.txt", FileMode.Open, FileAccess.Read, FileShare.Read)

Dim MyArray(50) As Byte

MyFile.Read(MyArray, 0, 50)

DoDangerousOperation(MyArray(20))

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.

Example 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.

Example 8

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.

(Bad Code)

Example Language: C

void host_lookup(char *user_supplied_addr){

struct hostent *hp;

in_addr_t *addr;

char hostname[64];

in_addr_t inet_addr(const char *cp);

/*routine that ensures user_supplied_addr is in the right format for conversion */

validate_addr_form(user_supplied_addr);

addr = inet_addr(user_supplied_addr);

hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);

strcpy(&hostname, hp->h_name);

}

If an attacker provides an address that appears to be well-formed, but the address does not resolve to a hostname, then the call to gethostbyaddr() will return NULL . When this occurs, a NULL pointer dereference (CWE-476) will occur in the call to strcpy().

Note that this example is also vulnerable to a buffer overflow (see CWE-119).

Observed Examples

Reference	Description
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.

Potential Mitigations

Phase: Implementation

Check the results of all functions that return a value and verify that the value is expected.

Effectiveness: High

Checking the return value of the function will typically be sufficient, however beware of race conditions (CWE-362) in a concurrent environment.

Phase: Implementation

Ensure that you account for all possible return values from the function.

Phase: Implementation

When designing a function, make sure you return a value or throw an exception in case of an error.

Background Details

Many functions will return some value about the success of their actions. This will alert the program whether or not to handle any errors caused by that function.

Relationships

Nature	Type	ID	Name	View(s) this relationship pertains to	Named Chain(s) this relationship pertains to
ChildOf	Weakness Class	227	Failure to Fulfill API Contract ('API Abuse')	Development Concepts (primary)699 Seven Pernicious Kingdoms (primary)700
ChildOf	Category	389	Error Conditions, Return Values, Status Codes	Development Concepts699
ChildOf	Category	728	OWASP Top Ten 2004 Category A7 - Improper Error Handling	Weaknesses in OWASP Top Ten (2004) (primary)711
ChildOf	Category	742	CERT C Secure Coding Section 08 - Memory Management (MEM)	Weaknesses Addressed by the CERT C Secure Coding Standard (primary)734
ChildOf	Weakness Class	754	Improper Check for Unusual or Exceptional Conditions	Research Concepts (primary)1000
CanPrecede	Weakness Base	476	NULL Pointer Dereference	Research Concepts1000	Unchecked Return Value to NULL Pointer Dereference690
StartsChain	Compound Element: Chain	690	Unchecked Return Value to NULL Pointer Dereference	Named Chains709	Unchecked Return Value to NULL Pointer Dereference690
PeerOf	Weakness Base	273	Improper Check for Dropped Privileges	Research Concepts1000

Taxonomy Mappings

Mapped Taxonomy Name	Node ID	Fit	Mapped Node Name
7 Pernicious Kingdoms			Unchecked Return Value
CLASP			Ignored function return value
OWASP Top Ten 2004	A7	CWE More Specific	Improper Error Handling
CERT C Secure Coding	MEM32-C		Detect and handle memory allocation errors

References

[REF-7] Mark Dowd, John McDonald and Justin Schuh. "The Art of Software Security Assessment". Chapter 7, "Program Building Blocks" Page 341.. 1st Edition. Addison Wesley. 2006.

[REF-11] M. Howard and D. LeBlanc. "Writing Secure Code". Chapter 20, "Checking Returns" Page 624. 2nd Edition. Microsoft. 2002.

Content History

Submissions
Submission Date	Submitter	Organization	Source
	7 Pernicious Kingdoms		Externally Mined

Modifications
Modification Date	Modifier	Organization	Source
2008-09-08	CWE Content Team	MITRE	Internal
2008-09-08	updated Common Consequences, Relationships, Other Notes, Taxonomy Mappings
2008-11-24	CWE Content Team	MITRE	Internal
2008-11-24	updated Relationships, Taxonomy Mappings
2009-01-12	CWE Content Team	MITRE	Internal
2009-01-12	updated Background Details, Demonstrative Examples, Description, Observed Examples, Other Notes, Potential Mitigations
2009-03-10	CWE Content Team	MITRE	Internal
2009-03-10	updated Relationships
2009-05-27	CWE Content Team	MITRE	Internal
2009-05-27	updated Demonstrative Examples
2009-07-27	CWE Content Team	MITRE	Internal
2009-07-27	updated Demonstrative Examples
2009-12-28	CWE Content Team	MITRE	Internal
2009-12-28	updated Common Consequences, Demonstrative Examples, References

CWE 252

COMPANY

STANDARDS

RECENT POSTS

MENU