CWE-252 未加检查的返回值

Unchecked Return Value

结构: Simple

Abstraction: Base

状态: Draft

被利用可能性: Low

基本描述

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

扩展描述

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.

相关缺陷

  • cwe_Nature: ChildOf cwe_CWE_ID: 754 cwe_View_ID: 1000 cwe_Ordinal: Primary

  • cwe_Nature: ChildOf cwe_CWE_ID: 754 cwe_View_ID: 1003 cwe_Ordinal: Primary

  • cwe_Nature: CanPrecede cwe_CWE_ID: 476 cwe_View_ID: 1000 cwe_Chain_ID: 690

适用平台

Language: {'cwe_Class': 'Language-Independent', 'cwe_Prevalence': 'Undetermined'}

常见的影响

范围 影响 注释
['Availability', 'Integrity'] ['Unexpected State', 'DoS: Crash, Exit, or Restart'] An unexpected return value could place the system in a state that could lead to a crash or other unintended behaviors.

可能的缓解方案

MIT-53 Implementation

策略:

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

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.

示例代码

Consider the following code segment:

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

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

bad C

int returnChunkSize(void ) {

/
if chunk info is valid, return the size of usable memory,

else, return -1 to indicate an error

/
...
}
int main() {
...
memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1));
...
}

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

bad 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:

None

The following examples read a file into a byte array.

bad C#

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 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);

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.

bad 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

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.

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

System.clearProperty("os.name");
...
String os = System.getProperty("os.name");
if (os.equalsIgnoreCase("Windows 95")) System.out.println("Not supported");

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.

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

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.

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.

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

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

bad C

void f(pthread_mutex_t mutex) {
pthread_mutex_lock(mutex);

/
access shared resource */


pthread_mutex_unlock(mutex);
}

However, the code does not check the value returned by pthread_mutex_lock() for errors. If pthread_mutex_lock() cannot acquire the mutex for any reason the function may introduce a race condition into the program and result in undefined behavior.

In order to avoid data races correctly written programs must check the result of thread synchronization functions and appropriately handle all errors, either by attempting to recover from them or reporting them to higher levels.

good

int f(pthread_mutex_t mutex) {
int result;

result = pthread_mutex_lock(mutex);
if (0 != result)
return result;


/
access shared resource */


return pthread_mutex_unlock(mutex);
}

分析过的案例

标识 说明 链接
CVE-2007-3798 Unchecked return value leads to resultant integer overflow and code execution. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3798
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. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4447
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. https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-2916
CVE-2008-5183 chain: unchecked return value can lead to NULL dereference https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-5183
CVE-2010-0211 chain: unchecked return value (CWE-252) leads to free of invalid, uninitialized pointer (CWE-824). https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-0211

分类映射

映射的分类名 ImNode 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 ERR33-C Imprecise Detect and handle standard library errors
CERT C Secure Coding POS54-C Imprecise Detect and handle POSIX library errors
The CERT Oracle Secure Coding Standard for Java (2011) EXP00-J Do not ignore values returned by methods
SEI CERT Perl Coding Standard EXP32-PL Exact Do not ignore function return values
Software Fault Patterns SFP4 Unchecked Status Condition
OMG ASCSM ASCSM-CWE-252-resource
OMG ASCRM ASCRM-CWE-252-data
OMG ASCRM ASCRM-CWE-252-resource

引用