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

Improper Handling of Length Parameter Inconsistency [CWE-130]

This weakness describes improper handling of a length field for associated data.

Created: October 23, 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

This weakness describes a situation when the length of attacker-controlled input is inconsistent with the length of associated data. An attacker might be able to pass a large input to application, which can result in buffer errors.

The following example demonstrates this weakness:

  1. // Improper Handling of Length Parameter Inconsistency [CWE-130] vulnerable code example
  2. // (c) HTB Research
  3. #include "StdAfx.h"
  4. #include <stdlib.h>
  5. #include <stdio.h>
  6. #include <string>
  7.  
  8. int main(int argc, char **argv[]) {
  9.   char secretString[6] = {'A','A','A','A','A'};
  10.   char buf1[5];
  11.   int iLen = 0;
  12.   int iLen2 = 0;
  13.   int i = 0;
  14.   iLen = argc;
  15.   for (i = 0; i< iLen;i++) {
  16.     buf1[i] = secretString[i];
  17.   }
  18.   iLen2 = strlen(secretString);
  19.   printf("The buffer is: %s\n",buf1);
  20.   printf("The secretString length buffer is : %d\n",iLen2);
  21.   printf("This is the secret: %s\n",secretString);
  22.   exit(0);
  23.   return 0;
  24. }

In the above example, the iLen variable is used to exit the loop and is equal to number of parameters passed to the application. Its length is not checked against the length if the secretString string. If the iLen variable is greater than the length of the secretString string, the buffer overread occurs as demonstrated by output of the secretString.

Let us have a look at another example. The following code snippet demonstrates an unexpected behavior of the application.

  1. // Improper Handling of Length Parameter Inconsistency [CWE-130] vulnerable code example
  2. // (c) HTB Research
  3. #include "StdAfx.h"
  4. #include <stdio.h>
  5. #include <stdlib.h>
  6.  
  7. int HandleData(char *data, int length) {
  8.   int isOK,index;
  9.   printf("Length is %d\n\n", length);
  10.   for (index = 0; index <= length; index++) {
  11.     printf("%c",data[index]);
  12.   }
  13.   return isOK;
  14. }
  15.  
  16. int main(int argc, char *argv[])
  17. {
  18.   char *data = "This is fake data from a TCP paquet";
  19.   int data_length = atoi(argv[1]);
  20.   HandleData(data,data_length);
  21. }

The HandleData() function receives two arguments. The first one is the data contained in the transmitted packet, and the second is the length of the data stream.

It is expected that the "length" variable is used to read data contained in the buffer. The following image demonstrates a normal behavior of the application:

CWE-130 PoC exploitation example
Figure - The first 20 bytes are read from the buffer

The application reads the buffer and obtains the first 20 bytes from it. In the next test we will try to read 2000 bytes from this buffer:

CWE-130 PoC exploitation example
Figure - The application read data outside the bounds

The length of the passed value is larger than the size of the buffer and application is able to read data outside of the bounds. A very large value can lead to application crash:

CWE-130 PoC exploitation example
Figure - The application crashes instantly when the passed value is equal to 20000 bytes

CWE-130 PoC exploitation example
Figure - The application crashes when the passed value is equal to 20000 bytes


This weakness is a child of CWE-119: Buffer errors.

2. Potential impact

An attacker, who controls input length, might be able to read or write data to arbitrary memory locations and gain access to potentially sensitive information, cause application crash or execute arbitrary code on the target system.

3. Attack patterns

This weakness has one CAPEC pattern:


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 does not perform memory management is potentially vulnerable to this weakness.

5. Severity and CVSS Scoring

This weakness could lead to memory disclosure, crash or execution of arbitrary code. In case of information disclosure it should be scored as C:P/I:N/A:N.

Information disclosure

This example demonstrates a case remote information disclosure:
5 (AV:N/AC:L/Au:N/C:P/I:N/A:N) – Medium severity.

Denial of service

If an attacker is able to crash the affected application, it should be scored as C:N/I:N/A:P:
5 (AV:N/AC:L/Au:N/C:N/I:N/A:P) – Medium severity.

Remote code execution

If application allows remote code execution, this weakness should be scored as:
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 this type of weakness is to perform checks on size fields. It is important to resolve any inconsistencies between the size of the field and the actual input data. When possible, avoid using attacker-controlled data to set the size of the buffer.

7. References

  1. CWE-130: Improper Handling of Length Parameter Inconsistency [cwe.mitre.org]

8. Latest HTB Security Advisories with CWE-130


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
Share
Let's Talk