Improper Handling of Length Parameter Inconsistency [CWE-130] — The Hacktivists

Improper Handling of Length Parameter Inconsistency is a security weakness that describes improper handling of a length field for associated data.

Table of Content
1. Description
2. Potential impact
3. Attack patterns
4. Affected software
5. Severity and CVSS Scoring

1. Description
………………………………

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

The following example demonstrates this weakness:

// Improper Handling of Length Parameter Inconsistency [CWE-130] vulnerable code example
// (c) HTB Research
#include "StdAfx.h"
#include <stdlib.h>
#include <stdio.h>
#include <string>
 
int main(int argc, char **argv[]) {
  char secretString[6] = {'A','A','A','A','A'};
  char buf1[5];
  int iLen = 0;
  int iLen2 = 0;
  int i = 0;
  iLen = argc;
  for (i = 0; i< iLen;i++) {
    buf1[i] = secretString[i];
  }
  iLen2 = strlen(secretString);
  printf("The buffer is: %s\n",buf1);
  printf("The secretString length buffer is : %d\n",iLen2);
  printf("This is the secret: %s\n",secretString);
  exit(0);
  return 0;
}

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

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

// Improper Handling of Length Parameter Inconsistency [CWE-130] vulnerable code example
// (c) HTB Research
#include "StdAfx.h"
#include <stdio.h>
#include <stdlib.h>
 
int HandleData(char *data, int length) {
  int isOK,index;
  printf("Length is %d\n\n", length);
  for (index = 0; index <= length; index++) {
    printf("%c",data[index]);
  }
  return isOK;
}
 
int main(int argc, char *argv[])
{
  char *data = "This is fake data from a TCP paquet";
  int data_length = atoi(argv[1]);
  HandleData(data,data_length);
}

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 the normal behaviour of the application:

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:

Figure — The application read data outside the bounds

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

Figure — The application crashes instantly when the passed value is equal to 20000 bytes

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 an application crash or execute arbitrary code on the target system.

3. Attack patterns
………………………………

This weakness has one CAPEC pattern:

❏ CAPEC-47: Buffer Overflow via Parameter Expansion

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 the case of information disclosure, it should be scored as C:L/I:N/A:N.

❏ Information disclosure
This example demonstrates a case of remote information disclosure:
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 an attacker is able to crash the affected application, it should be scored as C:N/I:N/A:H:
7.5 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H] — High severity.

❏ Remote code execution
If the application allows remote code execution, this weakness should be scored as:
9.8 [CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H] — Critical severity.

Credits: https://www.immuniweb.com/