1. Home
  2. CWE Database
  3. CWE-120
Base · Medium

CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')

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

CWE-120 · Base Level ·5 CVEs ·13 Mitigations

Description

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

Potential Impact

Integrity, Confidentiality, Availability

Modify Memory, Execute Unauthorized Code or Commands

Availability

Modify Memory, DoS: Crash, Exit, or Restart, DoS: Resource Consumption (CPU)

Demonstrative Examples

The following code asks the user to enter their last name and then attempts to store the value entered in the last_name array.
Bad
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.
The following code attempts to create a local copy of a buffer to perform some manipulations to the data.
Bad
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 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.
The code below calls the gets() function to read in data from the command line.
Bad
char buf[24];printf("Please enter your name and press <Enter>\n");gets(buf);...}
However, gets() is inherently unsafe, because it 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.
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.
Bad
...
                        struct hostent *clienthp;char hostname[MAX_LEN];
                           // create server socket, bind to server address and listen on socket...
                           // accept client connections and process requestsint 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.

Mitigations & Prevention

Requirements

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 ove

Architecture and Design

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 [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.

OperationBuild and Compilation Defense in Depth

Use automatic buffer overflow detection mechanisms that are offered by certain compilers or compiler extensions. Examples include: the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard, and ProPolice, which provide various mechanisms including canary-based detection and range/index checking. D3-SFCV (Stack Frame Canary Validation) from D3FEND [REF-1334] discusses canary-based detection in detail.

Implementation

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

Implementation

Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list 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 relat

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.

OperationBuild and Compilation Defense in Depth

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) [REF-58] [REF-60] and Position-Independent Executables (PIE) [REF-64]. Imported modules may be similarly realigned if their default memory addresses conflict with other mo

Operation Defense in Depth

Use a CPU and operating system that offers Data Execution Protection (using hardware NX or XD bits) or the equivalent techniques that simulate this feature in software, such as PaX [REF-60] [REF-61]. These techniques ensure that any instruction executed is exclusively at a memory address that is part of the code segment. For more information on these techniques see D3-PSEP (Process Segment Execution Prevention) from D3FEND [REF-1336].

Build and CompilationOperation

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.

Implementation Moderate

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

Detection Methods

  • Automated Static Analysis High — 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 generally does not account for environmental considerations when
  • 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
  • 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.
  • Automated Dynamic Analysis Moderate — Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518].
  • Automated Static Analysis - Binary or Bytecode High — According to SOAR [REF-1479], the following detection techniques may be useful:
  • Manual Static Analysis - Binary or Bytecode SOAR Partial — According to SOAR [REF-1479], the following detection techniques may be useful:

Real-World CVE Examples

CVE IDDescription
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-787: Out-of-bounds Write

The product writes data past the end, or before the beginning, of the intended buffer.

CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer'...

CWE-123: Write-what-where Condition

Any condition where the attacker has the ability to write an arbitrary value to an arbitrary location, often as the resu...

CWE-20: Improper Input Validation

The product receives input or data, but it does not validate or incorrectly validates that the input has the ...

Taxonomy Mappings

  • PLOVER: — Unbounded Transfer ('classic overflow')
  • 7 Pernicious Kingdoms: — Buffer Overflow
  • CLASP: — Buffer overflow
  • OWASP Top Ten 2004: A1 — Unvalidated Input
  • OWASP Top Ten 2004: A5 — Buffer Overflows
  • CERT C Secure Coding: STR31-C — Guarantee that storage for strings has sufficient space for character data and the null terminator
  • WASC: 7 — Buffer Overflow
  • Software Fault Patterns: SFP8 — Faulty Buffer Access
  • OMG ASCSM: ASCSM-CWE-120 —
  • OMG ASCRM: ASCRM-CWE-120 —

Frequently Asked Questions

What is CWE-120?

CWE-120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')) is a software weakness identified by MITRE's Common Weakness Enumeration. It is classified as a Base-level weakness. The product 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.

How can CWE-120 be exploited?

Attackers can exploit CWE-120 (Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')) to modify memory, execute unauthorized code or commands. This weakness is typically introduced during the Implementation phase of software development.

How do I prevent CWE-120?

Key mitigations include: 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

What is the severity of CWE-120?

CWE-120 is classified as a Base-level weakness (Medium abstraction). It has been observed in 5 real-world CVEs.