Base weakness

Draft

CWE-252: Unchecked Return Value

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

Recorded CVEs

With this primary weakness

KEVs

In the CISA KEV catalog

Low

Likelihood of exploit

Per MITRE

Base

Abstraction

MITRE classification

Overview

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

Code examples

Illustrative examples from MITRE showing how the weakness appears in code.

Consider the following code segment:

Vulnerable example

char buf[10], cp_buf[10];

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

In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:

Vulnerable example

int returnChunkSize(void *) {

If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788).

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

Vulnerable example

buf = (char*) malloc(req_size);

The following examples read a file into a byte array.

Vulnerable example

csharp

char[] byteArray = new char[1024];

Vulnerable example

java

FileInputStream fis;

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

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.

Vulnerable example

java

String itemName = request.getParameter(ITEM_NAME);

Vulnerable example

java

String itemName = request.Item(ITEM_NAME);

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.

Vulnerable example

java

System.clearProperty("os.name");

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 allow the program to die dereferencing a null value." But attackers are skilled at finding unexpected paths through programs, particularly when exceptions are involved.

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.

Vulnerable example

csharp

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

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.

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.

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.

Vulnerable example

void host_lookup(char *user_supplied_addr){

The following function attempts to acquire a lock in order to perform operations on a shared resource.

Vulnerable example

void f(pthread_mutex_t *mutex) {

Safe example

int f(pthread_mutex_t *mutex) {

CWE-252: Unchecked Return Value

Overview

Background

Real-world CVEs

Common consequences

How it happens

When it is introduced

How to prevent it

How to detect it

Automated Static Analysis

Code examples

Illustrative examples

Terminology & mappings

Mapped taxonomies

Frequently asked questions

What is CWE-252?

What CVEs are caused by CWE-252?

Is CWE-252 part of the OWASP Top 10?

How do you prevent CWE-252?

How is CWE-252 detected?

What are the consequences of CWE-252?

Is CWE-252 actively exploited?

References

Stay ahead of CWE-252

Overview

Background

Real-world CVEs

Common consequences

How it happens

When it is introduced

How to prevent it

How to detect it

Automated Static Analysis

Code examples

Illustrative examples

Related weaknesses

Parent

Child

Peer

Can precede

Terminology & mappings

Mapped taxonomies

Frequently asked questions

What is CWE-252?

What CVEs are caused by CWE-252?

Is CWE-252 part of the OWASP Top 10?

How do you prevent CWE-252?

How is CWE-252 detected?

What are the consequences of CWE-252?

Is CWE-252 actively exploited?

References

Stay ahead of CWE-252