Buffer Errors [CWE-119]

Buffer Errors weakness describes improper restriction of operations within the bounds of a memory buffer.

Created: September 11, 2012

Latest Update: July 29, 2020



Table of Content

Want to have an in-depth understanding of all modern aspects of Buffer Errors [CWE-119]? Read carefully this article and bookmark it to get back later, we regularly update this page.

1. Description

Buffer errors are common for software that performs operations on a memory buffer. Due to absence or improper validation of input data, an attacker might be able to read or write data outside the intended buffer. This weakness is often referred to as memory corruption. Certain languages allow direct memory addressing and do not automatically ensure that the addressed locations are valid for buffer that is being referenced. As a result, read and write operations might be performed on memory locations associated with another buffer, variables, data structures, etc.

In this paper we will cover some of the related weakness' classes:

1.1 CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') This is a classic buffer overflow, when application copies an input buffer of larger size into an output buffer. As a result, a buffer overflow occurs and data from the input buffer overwrites memory locations. The following example demonstrates an attempt to store the entered value into a buffer with size of 20 characters. If more data is passed to the aforementioned buffer and overflow occurs: // Buffer Errors [CWE-119] vulnerable code example // (c) HTB Research #include "StdAfx.h" #include <stdlib.h> #include <stdio.h> #include <string> int main ( int argc , char * argv [ ] ) { char input_data [ 20 ] ; printf ( "Enter your data: " ) ; scanf ( "%s" , input_data ) ; return 0 ; } 1.2 CWE-123: Write-what-where Condition This weakness describes a case where attacker can write arbitrary data to arbitrary locations in memory. As a result, it is possible to modify the EIP register and redirect execution flow to arbitrary code stored in memory: // Buffer Errors [CWE-119] vulnerable code example // (c) HTB Research #include "StdAfx.h" #include <stdlib.h> #include <stdio.h> #include <string> #define BUFSIZE 256 int main ( int argc , char * argv [ ] ) { char * buffer1 = ( char * ) malloc ( BUFSIZE ) ; char * buffer2 = ( char * ) malloc ( BUFSIZE ) ; strcpy ( buffer1 , argv [ 1 ] ) ; free ( buffer2 ) ; } The above example allocates two buffers with size of 256 each and copies user input into buffer1. Since buffer2 is allocated after buffer1 and there is no input validation performed on buffer1, the input data passed to buffer1 can overwrite accounting information that system keeps for buffer2, e.g. its contents and allocation header as well after the strcpy() call. The allocation header usually keeps a linked list of memory chunks. In our case there is a "previous" chunk (buffer1) and a "next" chunk (probably 0). When the free() call occurs, most memory allocation will rewrite the linked list using data from buffer2. This way the attacker is able to insert a memory address for the "next" chunk and the value to write into that memory address into "previous" chunk. The function pointer gets overwritten with memory address under attacker's control which might result in arbitrary code execution. 1.3 CWE-125: Out-of-bounds Read This weakness describes a case where a pointer or its index is used to access data beyond the bounds of intended buffer, resulting in access to potentially sensitive information, application crash or code execution. The following example in C briefly demonstrates the weakness: // Buffer Errors [CWE-119] vulnerable code example // (c) HTB Research int getValueFromArray ( int * array , int len , int index ) { int value ; if ( index < len ) { value = array [ index ] ; } else { printf ( "Value is: %d

" , array [ index ] ) ; value = - 1 ; } return value ; } The value of "index" is supposed to be lower than value of "len", this allows however a negative value to be passed as an array index. The error in code results in out of bound read and potentially allows access to sensitive information stored in memory. 1.4 CWE-130: Improper Handling of Length Parameter Inconsistency This weakness describes a situation when the length of attacker controlled input is inconsistent with length of the associated data. As a result, an attacker might be able to pass a large input to application that result in buffer errors. For more information, see: https://www.immuniweb.com/vulnerability/improper-handling-of-length-parameter-inconsistency.html 1.5 CWE-786: Access of Memory Location Before Start of Buffer This issue describes a case where software reads or writes to buffer using an index or a pointer that references a memory location prior to the beginning of the buffer. This error typically occurs, when a pointer or its index is decremented to a position that precedes the buffer, or when negative index is used. The following code uses the supplied number to output the corresponding element from an array. The error is triggered when a negative value is passed as an array index: // Buffer Errors [CWE-119] vulnerable code example // (c) HTB Research #include "StdAfx.h" #include <stdlib.h> #include <stdio.h> #include <string> int main ( int argc , char ** argv ) { char * items [ ] = { "item1" , "item2" , "item3" , "item4" } ; if ( argc != 2 ) { printf ( "You did not supply index

" ) ; return 1 ; } int index = atoi ( argv [ 1 ] ) ; printf ( "You selected %s

" , items [ index - 1 ] ) ; return 0 ; }

2. Potential impact

An attacker who controls the user input can read or write to arbitrary memory locations. As a result, it is possible to obtain potentially sensitive information from memory, it could also cause memory corruption and crash the application or even execute arbitrary code on the target system.

How to Detect Buffer Errors Vulnerabilities Free Website Security Test Non-intrusive GDPR Test

Non-intrusive PCI DSS Test Try Free Test ImmuniWeb® On-Demand Complete GDPR Audit

Complete PCI DSS Audit

Remediation Guidelines

DevSecOps Integration Learn More

3. Attack patterns

An attacker might use the following attack patterns to exploit this weakness:

Buffer overflow vulnerability is described as a common attack type under WASC-7 in WASC Threat Classification.

4. Affected software

Software written in languages such as C and C++ that do not perform memory management is potentially vulnerable to this weakness. The core of PHP is written in C, as a result PHP built-in functions have been susceptible to buffer error vulnerabilities.

5. Severity and CVSS Scoring

Buffer overflows can result in information disclosure, application or system crash or even execution of arbitrary code. When scoring this weakness, researchers should consider the maximum possible impact from the vulnerability.

Information disclosure

If there is a possibility to disclose certain parts of memory, the weakness should be scored as C:L/I:N/A:N.

In case of a remote attack against client application, the CVSS score is as follows:

5.3 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N] – Medium Severity.

Denial of service

If vulnerability is present in a software and exploitation of buffer overflow results in application crash it should be scored as C:N/I:N/A:H. But if the vulnerability could be used to crash or reboot the entire system it should be scored as S:C as well.

The following example can be used to score remotely exploitable vulnerability in a network service, which runs with SYSTEM privileges:

8.6 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H] – High Severity.

Code execution

If there is a possibility of code execution, the CVSS score should be C:H/I:H/A:H. For a remote attack vector, we recommend usage of the following CVSS metrics:

9.8 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] – Critical Severity.

6. Mitigations

The main approach in defending application from buffer errors is to perform checks on input data.

Certain compilers provide functionalities that might mitigate or eliminate exploitation possibilities for buffer errors, such as automatic buffer overflow detection. When compiling the application, developers should use Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE GCC flag, StackGuard or ProPolice.

There are certain built-in mechanisms in modern operating systems (such as DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization)) that can reduce the risk of successful buffer overflow exploitation. Windows users can also use EMET (http://support.microsoft.com/kb/2458544) to protect their systems from known vulnerabilities until patch is available.

7. References

8. Buffer Errors Vulnerabilities, Exploits and Examples

Copyright Disclaimer: Any above-mentioned content can be copied and used for non-commercial purposes only if proper credit to ImmuniWeb is given.