Unsachgemäße Behandlung von Längenparameter-Inkonsistenz

Beschreibung

Unsachgemäße Behandlung von Längenparameter-Inkonsistenz tritt auf, wenn ein Programm formatierte Nachrichten oder Datenstrukturen parst, aber Situationen, in denen ein Längenfeld nicht mit der tatsächlichen Länge der zugehörigen Daten übereinstimmt, nicht ordnungsgemäß behandelt. Wenn Längenparameter inkonsistent mit tatsächlichen Daten sind, kann das Programm über Puffergrenzen hinauslesen, falsche Datenmengen verarbeiten oder in unbeabsichtigte Speicherstellen schreiben. Diese Schwachstelle ist besonders häufig in Netzwerkprotokoll-Implementierungen, Dateiformat-Parsern und Serialisierungs-Handlern, wo explizite Längenfelder variabel langen Daten vorausgehen.

Risiko

Längenparameter-Inkonsistenzen sind hochgradig ausnutzbar, besonders in netzwerkfähigem Code. Angreifer können Längenfelder manipulieren, um Buffer-Over-Reads (Informationsoffenlegung) zu verursachen, wenn die Länge tatsächliche Daten überschreitet, oder Buffer-Overflows, wenn die Länge kleiner als bereitgestellte Daten ist. In Protokollen wie TLS ermöglichte genau diese Schwachstellenklasse Heartbleed (CVE-2014-0160). Speicheroffenlegung kann kryptografische Schlüssel, Passwörter und sensible Benutzerdaten offenlegen. Die Schwachstelle erfordert bei vielen Netzwerkprotokoll-Implementierungen keine Authentifizierung, was Remote-Exploitation unkompliziert macht.

Lösung

Validieren Sie immer, dass Längenparameter die tatsächliche Datengröße genau widerspiegeln, bevor Sie verarbeiten. Vertrauen Sie niemals benutzerbereitgestellten Längenwerten ohne Verifizierung. Implementieren Sie Minimum-von-(behauptete_Länge, tatsächliche_Datenlänge, Puffergröße)-Prüfungen. Verwenden Sie sichere Parsing-Bibliotheken, die Längenvalidierung automatisch handhaben. Fügen Sie explizite Grenzenprüfungen bei jedem Parsing-Schritt hinzu. Erwägen Sie die Verwendung von langen-präfixierten Datenformaten mit kryptografischen Integritätsprüfungen. Aktivieren Sie AddressSanitizer während der Entwicklung, um langenbezogene Speicherprobleme zu erkennen.

Häufige Auswirkungen

AuswirkungDetails
VertraulichkeitBereich: Informationsoffenlegung

Wenn die Länge tatsächliche Daten überschreitet, legen Lesezugriffe über den Puffer hinaus sensible Informationen aus angrenzendem Speicher offen (Heartbleed-artiger Angriff).
IntegritätBereich: Speicherbeschädigung

Wenn die Länge kleiner als Daten ist, können nachfolgende Schreiboperationen in angrenzende Strukturen überläufen.
VerfügbarkeitBereich: Denial-of-Service

Längeninkonsistenzen verursachen häufig Abstürze oder Ressourcenerschöpfung.

Beispielcode + Lösungscode

Anfälliger Code

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

// ANFÄLLIG: Vertraut Längenfeld ohne Validierung
void process_message(char *packet, size_t packet_len) {
    if (packet_len < 4) return;

    // Länge aus Nachrichten-Header lesen
    uint32_t claimed_len = *(uint32_t *)packet;

    // Basierend auf behaupteter Länge allokieren (könnte riesig sein)
    char *buffer = malloc(claimed_len);

    // claimed_len Bytes kopieren - Buffer-Over-Read wenn claimed_len > tatsächlich
    memcpy(buffer, packet + 4, claimed_len);

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

// ANFÄLLIG: Heartbleed-artiges Muster
void send_echo(char *payload, uint16_t claimed_len) {
    char response[65536];

    // Längenfeld nicht gegen tatsächliche Payload validiert
    memcpy(response, payload, claimed_len);  // Over-Read!

    send_response(response, claimed_len);
}

Korrigierter Code

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

// SICHER: Länge gegen tatsächliche Daten validieren
int process_message_safe(const char *packet, size_t packet_len) {
    if (packet_len < 4) {
        return -1;  // Nicht genug Daten für Header
    }

    uint32_t claimed_len = *(uint32_t *)packet;

    // Tatsächlich verfügbare Daten nach Header berechnen
    size_t actual_data_len = packet_len - 4;

    // Minimum von behaupteter und tatsächlicher Länge verwenden
    size_t copy_len = claimed_len < actual_data_len ? claimed_len : actual_data_len;

    // Maximale Allokation begrenzen
    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;
}

// SICHER: Heartbleed-Fix-Muster
int send_echo_safe(const char *payload, size_t actual_len,
                   uint16_t claimed_len) {
    char response[65536];

    // Minimum von behaupteter Länge, tatsächlicher Länge und Puffergröße verwenden
    size_t copy_len = claimed_len;
    if (copy_len > actual_len) {
        copy_len = actual_len;  // Nicht über tatsächliche Daten hinaus lesen
    }
    if (copy_len > sizeof(response)) {
        copy_len = sizeof(response);  // Response nicht überläufen
    }

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

Ausgenutzt in der Praxis

Heartbleed (OpenSSL TLS, 2014)

CVE-2014-0160 ist das kanonische Beispiel für Ausnutzung von Längenparameter-Inkonsistenz. Die TLS-Heartbeat-Erweiterung ermöglichte Angreifern, Anfragen mit Längenfeldern zu senden, die größer als tatsächliche Payloads waren, was OpenSSL veranlasste, bis zu 64KB Serverspeicher pro Anfrage zurückzugeben. Betroffen waren 17% der SSL-Websites.

MongoDB Server-Speicheroffenlegung (MongoDB, 2025)

CVE-2025-14847 betrifft MongoDB-Server's Zlib-komprimierte Protokoll-Header. Nicht übereinstimmende Längenfelder ermöglichen nicht authentifizierten Remote-Angreifern, nicht initialisierten Heap-Speicher zu lesen, was potenziell sensible Daten offenlegt. Betroffen sind Versionen 3.6 bis ungepatchte 8.x.

Industrielle Steuerungssysteme (Mehrere, fortlaufend)

Mehrere CWE-130-Schwachstellen wurden in Honeywell Experion PKS, Safety Manager und Mitsubishi Electric MELSEC/MELIPC-Serie industriellen Steuerungssystemen gefunden, die kritische Infrastruktur betreffen.


Tools zum Testen/Ausnutzen

  • AFL++ — Fuzzer, der effektiv bei der Entdeckung von Längenfeldverarbeitungsfehlern ist.

  • AddressSanitizer — erkennt Speicherzugriffsverletzungen durch Längeninkonsistenzen.

  • Burp Suite — Längenfelder in Netzwerkprotokollen manipulieren.


CVE-Beispiele

  • CVE-2014-0160 — Heartbleed: TLS-Längenfeld verursacht massive Speicheroffenlegung.

  • CVE-2025-14847 — MongoDB Zlib-Header-Längeninkonsistenz.

  • CVE-2023-26048 — Eclipse Jetty Längenparameter-Behandlung DoS.


Referenzen

  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/