CWE Glossary

CWE is a trademark of the MITRE Corporation.

Stay in touch

Application security insights and invitations to exclusive events in your inbox

Your data will stay confidential Private and Confidential

Buffer Errors [CWE-119]

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

Created: September 11, 2012
Latest Update: August 5, 2015

Table of Content

  1. Description
  2. Potential impact
  3. Attack patterns
  4. Affected software
  5. Severity and CVSS Scoring
  6. Mitigations
  7. References
  8. Latest Related Security Advisories

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:

  1. // Buffer Errors [CWE-119] vulnerable code example
  2. // (c) HTB Research
  3. #include "StdAfx.h"
  4. #include <stdlib.h>
  5. #include <stdio.h>
  6. #include <string>
  8. int main( int argc, char *argv[] )
  9. {
  10.   char input_data[20];
  11.   printf ("Enter your data: ");
  12.   scanf ("%s", input_data);
  13.   return 0;
  14. }

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:

  1. // Buffer Errors [CWE-119] vulnerable code example
  2. // (c) HTB Research
  3. #include "StdAfx.h"
  4. #include <stdlib.h>
  5. #include <stdio.h>
  6. #include <string>
  7. #define BUFSIZE 256
  9. int main( int argc, char *argv[] )
  10. {
  11.   char *buffer1 = (char *) malloc(BUFSIZE);
  12.   char *buffer2 = (char *) malloc(BUFSIZE);
  13.   strcpy(buffer1, argv[1]);
  14.   free(buffer2);
  15. }

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:

  1. // Buffer Errors [CWE-119] vulnerable code example
  2. // (c) HTB Research
  3. int getValueFromArray(int *array, int len, int index) {
  4.   int value;
  5.   if (index < len)
  6.   {
  7.     value = array[index];
  8.   }
  9.   else
  10.   {
  11.     printf("Value is: %d\n", array[index]);
  12.     value = -1;
  13.   }
  14.   return value;
  15. }

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:

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:

  1. // Buffer Errors [CWE-119] vulnerable code example
  2. // (c) HTB Research
  3. #include "StdAfx.h"
  4. #include <stdlib.h>
  5. #include <stdio.h>
  6. #include <string>
  8. int main (int argc, char **argv) {
  9.   char *items[] = {"item1", "item2", "item3", "item4"};
  10.   if (argc!=2)
  11.   {
  12.     printf("You did not supply index\n");
  13.     return 1;
  14.   }
  16.   int index = atoi(argv[1]);
  17.   printf("You selected %s\n", items[index-1]);
  18.   return 0;
  19. }

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 sould also cause memory corruption and crash the application or even execute arbitrary code on the target system.

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.

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:P/I:N/A:N.

In case of a remote attack against client application, the CVSS score is as follows:
4.3 (AV:N/AC:M/Au:N/C:P/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:P. But if the vulnerability could be used to crash or reboot the entire system it should be scored as C:N/I:N/A:C.

The following example can be used to score remotely exploitable vulnerability in a network service, which runs with SYSTEM privileges:
7.8 (AV:N/AC:L/Au:N/C:N/I:N/A:C) – High Severity.

Code execution

If there is a possibility of code execution, the CVSS score should be C:C/I:C/A:C. For a remote attack vector, we recommend usage of the following CVSS metrics:
10 (AV:N/AC:L/Au:N/C:C/I:C/A:C) – Critical Severity.

We use CVSSv2 scoring system in our HTB Security Advisories to calculate the risk of the discovered vulnerabilities. Not all of the vulnerabilities are scored in strict accordance to FIRST recommendations. Our CVSSv2 scores are based on our long internal experience in software auditing and penetration testing, taking into consideration a lot of practical nuances and details. Therefore, sometimes they may differ from those ones that are recommended by FIRST.

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 ( to protect their systems from known vulnerabilities until patch is available.

7. References

  1. CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer []
  2. Basic Buffer Overflow Exploitation Explained []
  3. The Enhanced Mitigation Experience Toolkit []
  4. Compiler Security Checks In Depth []
  5. GCC Stack Smashing Protector []
  6. Protection against buffer overflows []
  7. Adding stack smashing protection to GCC v3.4 []

8. Latest HTB Security Advisories with CWE-119

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

↑ Back to Top
High-Tech Bridge on Facebook High-Tech Bridge on Twitter High-Tech Bridge on LinkedIn High-Tech Bridge RSS Feeds Send by Email
Let's Talk