CWE Glossary
- CWE-22: Path Traversal
- CWE-78: OS Command Injection
- CWE-79: Cross-Site Scripting
- CWE-89: SQL Injection
- CWE-90: LDAP Injection
- CWE-91: XML Injection
- CWE-94: Code Injection
- CWE-98: PHP File Inclusion
- CWE-113: HTTP Response Splitting
- CWE-119: Buffer Errors
- CWE-130: Improper Handling of Length Parameter Inconsistency
- CWE-193: Off-by-one Error
- CWE-200: Information Exposure
- CWE-211: Information Exposure Through Externally-Generated Error Message
- CWE-236: Improper Handling of Undefined Parameters
- CWE-276: Incorrect Default Permissions
- CWE-284: Improper Access Control
- CWE-285: Improper Authorization
- CWE-287: Improper Authentication
- CWE-297: Improper Validation of Certificate with Host Mismatch
- CWE-306: Missing Authentication for Critical Function
- CWE-312: Cleartext Storage of Sensitive Information
- CWE-345: Insufficient Verification of Data Authenticity
- CWE-352: Cross-Site Request Forgery
- CWE-384: Session Fixation
- CWE-427: Uncontrolled Search Path Element
- CWE-434: Unrestricted Upload of File with Dangerous Type
- CWE-476: NULL Pointer Dereference
- CWE-521: Weak Password Requirements
- CWE-601: Open Redirect
- CWE-611: Improper Restriction of XML External Entity Reference ('XXE')
- CWE-613: Insufficient Session Expiration
- CWE-618: Exposed Unsafe ActiveX Method
- CWE-671: Lack of Administrator Control over Security
- CWE-798: Use of Hard-coded Credentials
- CWE-799: Improper Control of Interaction Frequency
- CWE-822: Untrusted Pointer Dereference
- CWE-835: Infinite Loop
- CWE-918: Server-Side Request Forgery (SSRF)
- CWE-942: Overly Permissive Cross-domain Whitelist
CWE is a trademark of the MITRE Corporation.
Join our subscribers
Improper Handling of Length Parameter Inconsistency [CWE-130]
Improper Handling of Length Parameter Inconsistency is a security weakness that describes improper handling of a length field for associated data.
![Improper Handling of Length Parameter Inconsistency [CWE-130]](/images/vulnerability/previews/improper-handling-of-length-parameter-inconsistency-cwe-130.jpg "Improper Handling of Length Parameter Inconsistency [CWE-130]")
Created: October 23, 2012
Latest Update: December 29, 2020
Table of Content
- Description
- Potential impact
- Attack patterns
- Affected software
- Severity and CVSS Scoring
- Mitigations
- References
- Latest Related Security Advisories
Want to have an in-depth understanding of all modern aspects of Improper Handling of Length Parameter Inconsistency [CWE-130]? Read carefully this article and bookmark it to get back later, we regularly update this page.
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:
- // 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 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.
- // 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 a normal behavior 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 application is able to read data outside of the bounds. A very large value can lead to 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 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 case of information disclosure it should be scored as C:L/I:N/A:N.
Information disclosure
This example demonstrates a case 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 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.
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
- CWE-130: Improper Handling of Length Parameter Inconsistency [cwe.mitre.org]
8. Improper Handling of Length Parameter Inconsistency 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.
↑ Back to Top
