Improper Handling of Length Parameter Inconsistency

Description

Improper Handling of Length Parameter Inconsistency occurs when a program parses formatted messages or data structures but fails to properly handle situations where a length field does not match the actual length of the associated data. When length parameters are inconsistent with actual data, the program may read beyond buffer boundaries, process incorrect amounts of data, or write to unintended memory locations. This vulnerability is particularly common in network protocol implementations, file format parsers, and serialization handlers where explicit length fields precede variable-length data.

Risk

Length parameter inconsistencies are highly exploitable, particularly in network-facing code. Attackers can manipulate length fields to cause buffer over-reads (information disclosure) when the length exceeds actual data, or buffer overflows when length is smaller than provided data. In protocols like TLS, this exact vulnerability class enabled Heartbleed (CVE-2014-0160). Memory disclosure can expose cryptographic keys, passwords, and sensitive user data. The vulnerability requires no authentication in many network protocol implementations, making remote exploitation straightforward.

Solution

Always validate that length parameters accurately reflect the actual data size before processing. Never trust user-supplied length values without verification. Implement minimum of (claimed_length, actual_data_length, buffer_size) checks. Use safe parsing libraries that handle length validation automatically. Add explicit boundary checks at each parsing step. Consider using length-prefixed data formats with cryptographic integrity checks. Enable AddressSanitizer during development to catch length-related memory issues.

Common Consequences

ImpactDetails
ConfidentialityScope: Information Disclosure

When length exceeds actual data, reads beyond buffer expose sensitive information from adjacent memory (Heartbleed-style attack).
IntegrityScope: Memory Corruption

When length is smaller than data, subsequent writes may overflow into adjacent structures.
AvailabilityScope: Denial of Service

Length inconsistencies commonly cause crashes or resource exhaustion.

Example Code + Solution Code

Vulnerable Code

#include <string.h>
#include <stdlib.h>

// VULNERABLE: Trusts length field without validation
void process_message(char *packet, size_t packet_len) {
    if (packet_len < 4) return;

    // Read length from message header
    uint32_t claimed_len = *(uint32_t *)packet;

    // Allocate based on claimed length (could be huge)
    char *buffer = malloc(claimed_len);

    // Copy claimed_len bytes - buffer over-read if claimed_len > actual
    memcpy(buffer, packet + 4, claimed_len);

    process_data(buffer, claimed_len);
    free(buffer);
}

// VULNERABLE: Heartbleed-like pattern
void send_echo(char *payload, uint16_t claimed_len) {
    char response[65536];

    // Length field not validated against actual payload
    memcpy(response, payload, claimed_len);  // Over-read!

    send_response(response, claimed_len);
}

Fixed Code

#include <string.h>
#include <stdlib.h>
#include <stdint.h>

// SAFE: Validate length against actual data
int process_message_safe(const char *packet, size_t packet_len) {
    if (packet_len < 4) {
        return -1;  // Not enough data for header
    }

    uint32_t claimed_len = *(uint32_t *)packet;

    // Calculate actual data available after header
    size_t actual_data_len = packet_len - 4;

    // Use minimum of claimed and actual length
    size_t copy_len = claimed_len < actual_data_len ? claimed_len : actual_data_len;

    // Limit maximum allocation
    if (copy_len > MAX_MESSAGE_SIZE) {
        return -1;
    }

    char *buffer = malloc(copy_len);
    if (!buffer) return -1;

    memcpy(buffer, packet + 4, copy_len);

    process_data(buffer, copy_len);
    free(buffer);
    return 0;
}

// SAFE: Heartbleed fix pattern
int send_echo_safe(const char *payload, size_t actual_len,
                   uint16_t claimed_len) {
    char response[65536];

    // Use minimum of claimed length, actual length, and buffer size
    size_t copy_len = claimed_len;
    if (copy_len > actual_len) {
        copy_len = actual_len;  // Don't read beyond actual data
    }
    if (copy_len > sizeof(response)) {
        copy_len = sizeof(response);  // Don't overflow response
    }

    memcpy(response, payload, copy_len);
    send_response(response, copy_len);
    return 0;
}

Exploited in the Wild

Heartbleed (OpenSSL TLS, 2014)

CVE-2014-0160 is the canonical example of length parameter inconsistency exploitation. The TLS heartbeat extension allowed attackers to send requests with length fields larger than actual payloads, causing OpenSSL to return up to 64KB of server memory per request. Affected 17% of SSL websites.

MongoDB Server Memory Disclosure (MongoDB, 2025)

CVE-2025-14847 affects MongoDB Server's Zlib compressed protocol headers. Mismatched length fields allow unauthenticated remote attackers to read uninitialized heap memory, potentially exposing sensitive data. Affects versions 3.6 through unpatched 8.x.

Industrial Control Systems (Multiple, Ongoing)

Multiple CWE-130 vulnerabilities have been found in Honeywell Experion PKS, Safety Manager, and Mitsubishi Electric MELSEC/MELIPC series industrial control systems, affecting critical infrastructure.


Tools to test/exploit

  • AFL++ — fuzzer effective at discovering length field handling bugs.

  • AddressSanitizer — detects memory access violations from length inconsistencies.

  • Burp Suite — manipulate length fields in network protocols.


CVE Examples

  • CVE-2014-0160 — Heartbleed: TLS length field causing massive memory disclosure.

  • CVE-2025-14847 — MongoDB Zlib header length inconsistency.

  • CVE-2023-26048 — Eclipse Jetty length parameter handling DoS.


References

  1. MITRE. "CWE-130: Improper Handling of Length Parameter Inconsistency." https://cwe.mitre.org/data/definitions/130.html

  2. Heartbleed.com. "The Heartbleed Bug." https://heartbleed.com/