CWE-130, Improper Handling of Length Parameter Inconsistency, applies when the product parses a formatted message or structure but does not handle, or mishandles, a length field that is inconsistent with the actual length of the associated data.
Almost every binary protocol and file format carries lengths: TLS records, DNS messages, HTTP Content-Length, image chunks, archive headers. MITRE lists C, C++, and also not language-specific and not technology-specific as platforms, because the flaw is about trusting a number, not about a particular language.
How it happens
A sender writes "the next 500 bytes are the payload". The receiver reads that number and acts on it. If the real payload is 10 bytes, or if the number is zero, negative or enormous, the receiver can go wrong in several ways.
MITRE explains the attacker's motives. One is to pass in arbitrarily large input. Another is to modify application state by including invalid data for later properties. Such weaknesses commonly lead to buffer overflows and execution of arbitrary code.
The observed examples show the spread.
- CVE-2014-0160, Heartbleed, is described by MITRE as a chain where an inconsistent length parameter enabled an out-of-bounds read that returned memory which could include private cryptographic keys and other sensitive data.
- CVE-2009-2299: a web application firewall consumes excessive memory when an HTTP request contains a large Content-Length value but no POST data.
- CVE-2001-1186: a web server can be made to deny service with a request whose content-length is larger than the size of the request, which prevents the server from timing out the connection.
- CVE-2001-0825: a length argument of zero or less disables the length check, which allows a buffer overflow.
// Vulnerable: trusts the declared length
struct msg { uint16_t len; uint8_t data[]; };
void handle(const uint8_t *buf, size_t buflen) {
const struct msg *m = (const struct msg *)buf;
uint8_t copy[256];
memcpy(copy, m->data, ntohs(m->len)); // len is attacker controlled
}
What an attacker gains
MITRE lists confidentiality and integrity impact, with reading and modifying memory, varying by context. In practice the outcomes include:
- memory disclosure through over-reads,
- memory corruption through overflows,
- memory or connection exhaustion when a huge declared length makes the server wait for or reserve data that never arrives.
How to find it
MITRE names automated static analysis as able to find some instances. Add these checks.
- Write tests where the length field is zero, one past the actual data, negative when signed, and the maximum value.
- Fuzz parsers with structure-aware inputs that mutate length fields.
- Review every place a length from the wire is used in a copy, allocation or loop bound.
How to fix it
The record lists no mitigations. These steps follow from the definition.
- Compare the declared length with the number of bytes actually available before using it.
- Reject lengths that are zero when zero is invalid, and cap lengths at a sane maximum.
- Use unsigned types and check for wrap-around when adding header sizes.
- Apply timeouts and total size limits so a promised but missing body cannot hold resources.
- Fail the whole message on inconsistency instead of guessing.
// Fixed: every length is checked against what exists
int handle(const uint8_t *buf, size_t buflen) {
if (buflen < sizeof(uint16_t)) return -1;
uint16_t len = ((uint16_t)buf[0] << 8) | buf[1];
if (len > buflen - 2 || len > 256) return -1;
uint8_t copy[256];
memcpy(copy, buf + 2, len);
return 0;
}
Quick check
What is the one rule that prevents most of these bugs?
Never use a length from the input until you have compared it to the amount of data you really have and to a maximum your code can handle.
Why does a huge Content-Length matter even without a memory bug?
A server may wait for or reserve resources for data that never arrives. MITRE's examples include excessive memory use and a connection that never times out.
