用户工具

站点工具


cwe:cn:definition:120

CWE-120:未进行输入大小检查的缓冲区拷贝(传统缓冲区溢出)

Description Summary

The program copies an input buffer to an output buffer without verifying that the size of the input buffer is less than the size of the output buffer, leading to a buffer overflow.

Extended Description

A buffer overflow condition exists when a program attempts to put more data in a buffer than it can hold, or when a program attempts to put data in a memory area outside of the boundaries of a buffer. The simplest type of error, and the most common cause of buffer overflows, is the “classic” case in which the program copies the buffer without restricting how much is copied. Other variants exist, but the existence of a classic overflow strongly suggests that the programmer is not considering even the most basic of security protections.

Likelihood of Exploit

High to Very High

Common Consequences

Scope Technical Impace Note
Integrity
Confidentiality
Availability
Execute unauthorized code or commandsBuffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. This can often be used to subvert any other security service.
AvailabilityDoS: crash / exit / restart
DoS: resource consumption (CPU)
Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop.

Detection Methods

Detection Method - 1

Automated Static Analysis

This weakness can often be detected using automated static analysis tools. Many modern tools use data flow analysis or constraint-based techniques to minimize the number of false positives.

Automated static analysis might not be able to recognize when proper input validation is being performed, leading to false positives - i.e., warnings that do not have any security consequences or do not require any code changes.

Automated static analysis might not be able to detect the usage of custom API functions or third-party libraries that indirectly invoke SQL commands, leading to false negatives - especially if the API/library code is not available for analysis.

This is not a perfect solution, since 100% accuracy and coverage are not feasible.
2013/05/30 09:36

Detection Method - 2

Automated Dynamic Analysis

This weakness can be detected using dynamic tools and techniques that interact with the software using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The software's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

2013/05/30 09:36

Detection Method - 3

Manual Analysis

Manual analysis can be useful for finding this weakness, but it might not achieve desired code coverage within limited time constraints. This becomes difficult for weaknesses that must be considered for all inputs, since the attack surface can be too large.

2013/05/30 09:36

Detection Method - 4

Automated Static Analysis - Binary / Bytecode

According to SOAR, the following detection techniques may be useful:

Detection Method - 5

Manual Static Analysis - Binary / Bytecode

According to SOAR, the following detection techniques may be useful:

Detection Method - 6

=== Dynamic Analysis with automated results interpretation === According to SOAR, the following detection techniques may be useful:

Detection Method - 7

Dynamic Analysis with manual results interpretation

According to SOAR, the following detection techniques may be useful:

Detection Method - 8

Manual Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Detection Method - 9

Automated Static Analysis - Source Code

According to SOAR, the following detection techniques may be useful:

Detection Method - 10

Architecture / Design Review

According to SOAR, the following detection techniques may be useful:

Potential Mitigations

Mitigation - 1

Requirements

Strategy:Language Selection

Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer.

Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.

2013/05/30 09:37

Mitigation - 2

Architecture and Design

Strategy:Libraries or Frameworks

Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.

Examples include the Safe C String Library (SafeStr) by Messier and Viega [R.805.6], and the Strsafe.h library from Microsoft [R.805.7]. These libraries provide safer versions of overflow-prone string-handling functions.

2013/05/30 09:37

Mitigation - 3

Build and Compilation

Strategy:Compilation or Build Hardening

Run or compile the software using features or extensions that automatically provide a protection mechanism that mitigates or eliminates buffer overflows.

For example, certain compilers and extensions provide automatic buffer overflow detection mechanisms that are built into the compiled code. Examples include the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice.

2013/05/30 09:37

Mitigation - 4

Implementation

Consider adhering to the following rules when allocating and managing an application's memory:

2013/05/30 09:37

Mitigation - 5

Implementation

Strategy:Input Validation

Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a whitelist of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”

Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a blacklist). A blacklist is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, blacklists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

2013/05/30 09:37

Mitigation - 6

Architecture and Design

For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.

2013/05/30 09:37

Mitigation - 7

Operation

Strategy:Environment Hardening

Run or compile the software using features or extensions that randomly arrange the positions of a program's executable and libraries in memory. Because this makes the addresses unpredictable, it can prevent an attacker from reliably jumping to exploitable code.

Examples include Address Space Layout Randomization (ASLR) [R.806.3] [R.806.5] and Position-Independent Executables (PIE) [R.806.7].

2013/05/30 09:37

Mitigation - 8

Operation

Strategy:Environment Hardening

Use a CPU and operating system that offers Data Execution Protection (NX) or its equivalent [R.806.5] [R.806.6].

2013/05/30 09:37

Mitigation - 9

Build and Compilation Operation

Most mitigating technologies at the compiler or OS level to date address only a subset of buffer overflow problems and rarely provide complete protection against even that subset. It is good practice to implement strategies to increase the workload of an attacker, such as leaving the attacker to guess an unknown value that changes every program execution.

Mitigation - 10

Implementation

Replace unbounded copy functions with analogous functions that support length arguments, such as strcpy with strncpy. Create these if they are not available.

2013/05/30 09:37

Mitigation - 11

Architecture and Design

Strategy:Enforcement by Conversion

When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.

2013/05/30 09:37

Mitigation - 12

Architecture and Design Operation

Strategy:Environment Hardening

Run your code using the lowest privileges that are required to accomplish the necessary tasks [R.98.2]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.

2013/05/30 09:37

Mitigation - 13

Architecture and Design Operation

Strategy:Sandbox or Jail

Run the code in a “jail” or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.

OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.

This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.

Be careful to avoid CWE-243 and other weaknesses related to jails.

2013/05/30 09:37

Demonstrative Examples

Example - 1

The following code asks the user to enter their last name and then attempts to store the value entered in the last_name array.

char last_name[20]; 
printf ("Enter your last name: "); 
scanf ("%s", last_name); 

The problem with the code above is that it does not restrict or limit the size of the name entered by the user. If the user enters “Very_very_long_last_name” which is 24 characters long, then a buffer overflow will occur since the array can only hold 20 characters total.

Example - 2

The following code attempts to create a local copy of a buffer to perform some manipulations to the data.

void manipulate_string(char * string){ 
char buf[24]; 
strcpy(buf, string); 
... 
 
} 

However, the programmer does not ensure that the size of the data pointed to by string will fit in the local buffer and blindly copies the data with the potentially dangerous strcpy() function. This may result in a buffer overflow condition if an attacker can influence the contents of the string parameter.

2013/05/30 09:37

Example - 3

The code below calls the gets() function to read in data from the command line.

char buf[24]; 
printf("Please enter your name and press <Enter>\n"); 
gets(buf); 
... 
 
} 

However, the programmer uses the function gets() which is inherently unsafe because it blindly copies all input from STDIN to the buffer without checking size. This allows the user to provide a string that is larger than the buffer size, resulting in an overflow condition.

2013/05/30 09:37

Example - 4

In the following example, a server accepts connections from a client and processes the client request. After accepting a client connection, the program will obtain client information using the gethostbyaddr method, copy the hostname of the client that connected to a local variable and output the hostname of the client to a log file.

... 
struct hostent *clienthp; 
char hostname[MAX_LEN]; 
 
// create server socket, bind to server address and listen on socket 
... 
 
// accept client connections and process requests 
int count = 0; 
for (count = 0; count < MAX_CONNECTIONS; count++) { 
 
int clientlen = sizeof(struct sockaddr_in); 
int clientsocket = accept(serversocket, (struct sockaddr *)&clientaddr, &clientlen); 
 
if (clientsocket >= 0) { 
clienthp = gethostbyaddr((char*) &clientaddr.sin_addr.s_addr, sizeof(clientaddr.sin_addr.s_addr), AF_INET); 
strcpy(hostname, clienthp->h_name); 
logOutput("Accepted client connection from host ", hostname); 
 
// process client request 
... 
close(clientsocket); 
 
} 
 
} 
close(serversocket); 
 
... 

However, the hostname of the client that connected may be longer than the allocated size for the local hostname variable. This will result in a buffer overflow when copying the client hostname to the local variable using the strcpy method.

Observed Examples

Reference Description
CVE-2000-1094buffer overflow using command with long argument
CVE-1999-0046buffer overflow in local program using long environment variable
CVE-2002-1337buffer overflow in comment characters, when product increments a counter for a ”>” but does not decrement for ”<”
CVE-2003-0595By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
CVE-2001-0191By replacing a valid cookie value with an extremely long string of characters, an attacker may overflow the application's buffers.
cwe/cn/definition/120.txt · 最后更改: 2014/09/04 14:25 (外部编辑)