Write-what-where-Bedingung

Beschreibung

Die Write-what-where-Bedingung ist eine Schwachstelle, bei der ein Angreifer einen beliebigen Wert an eine beliebige Speicherstelle schreiben kann. Dieses mächtige Exploitation-Primitiv resultiert typischerweise aus Buffer Overflows, Format-String-Schwachstellen oder anderen Speicherbeschädigungs-Bugs, die Angreifern Kontrolle über sowohl die Schreibadresse als auch den geschriebenen Wert geben. Wenn Angreifer Write-what-where-Fähigkeit erreichen, können sie jeden beschreibbaren Speicher überschreiben, einschließlich Funktionspointer, GOT-Einträge, Rücksprungadressen oder sicherheitskritische Variablen. Diese Schwachstellenklasse repräsentiert eines der gefährlichsten verfügbaren Exploitation-Primitive.

Risiko

Write-what-where-Bedingungen sind extrem gefährlich, weil sie Angreifern direkte, beliebige Speicher-Schreibfähigkeit bieten. Ein einzelnes Write-what-where-Primitiv kann genutzt werden, um Code-Ausführung durch verschiedene Techniken zu erreichen: Überschreiben von GOT-Einträgen, um Funktionsaufrufe umzuleiten, Beschädigen von Funktionspointern, Modifizieren von Sicherheits-Flags oder Installieren von Hooks in kritischen Codepfaden. Moderne Exploits verketten oft schwächere Schwachstellen, um Write-what-where-Fähigkeit als Zwischenschritt zur vollständigen Kontrolle zu erreichen. Die Schwachstelle betrifft Software auf allen Plattformen einschließlich Betriebssysteme, Browser, Hardware-Firmware und Embedded-Geräte.

Lösung

Eliminieren Sie die zugrundeliegenden Schwachstellen, die Write-what-where-Bedingungen ermöglichen: beheben Sie Buffer Overflows, Format-String-Bugs und Integer-Overflows. Implementieren Sie speichersichere Programmierpraktiken mit Grenzenprüfung bei allen Schreiboperationen. Verwenden Sie Compiler-Schutzmaßnahmen: ASLR zur Randomisierung des Speicherlayouts, Stack-Canaries, Control Flow Integrity (CFI) und schreibgeschützte Speicherbereiche. Aktivieren Sie Hardware-Schutzmaßnahmen wie Intel CET (Control-flow Enforcement Technology). Verwenden Sie speichersichere Sprachen (Rust, Go) für neue Entwicklung. Führen Sie gründliche Code-Audits durch mit Fokus auf Pointer-Arithmetik und Array-Indizierung.

Häufige Auswirkungen

AuswirkungDetails
ZugriffskontrolleBereich: Code-Ausführung

Beliebiges Schreiben ermöglicht das Überschreiben von Funktionspointern, GOT-Einträgen oder Rücksprungadressen, um den Ausführungsfluss zu kapern.
IntegritätBereich: Integrität

Jeder beschreibbare Speicher kann modifiziert werden, einschließlich sicherheitskritischer Variablen, Konfigurationsdaten oder Heap-Metadaten.
VertraulichkeitBereich: Vertraulichkeit

Schreib-Primitive können mit Lese-Primitiven verkettet werden, um sensible Daten zu leaken oder ASLR zu umgehen.

Beispielcode + Lösungscode

Anfälliger Code

#include <string.h>

// ANFÄLLIG: Write-what-where über kontrollierten Index
void write_log_entry(int *log_buffer, int index, int value) {
    // Angreifer kontrolliert Index - kann überall relativ zu log_buffer schreiben
    log_buffer[index] = value;  // Write-what-where wenn Index nicht validiert
}

// ANFÄLLIG: Format-String bietet Write-what-where
void log_message(char *user_input) {
    // %n schreibt Anzahl gedruckter Bytes an Adresse auf Stack
    // Angreifer kann Format-Specifier nutzen, um beliebiges Schreiben zu erreichen
    printf(user_input);  // Write-what-where über %n Format-Specifier
}

// ANFÄLLIG: Heap-Metadaten-Beschädigung
void heap_overflow_www(char *user_data, size_t len) {
    char *buf = malloc(32);
    memcpy(buf, user_data, len);  // Overflow beschädigt Heap-Metadaten
    free(buf);  // Unlink-Operation bietet Write-what-where
}

Korrigierter Code

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

// SICHER: Grenzenprüfung für Array-Schreiben
int write_log_entry_safe(int *log_buffer, size_t buffer_size, size_t index, int value) {
    // Validieren, dass Index innerhalb der Grenzen ist
    if (index >= buffer_size) {
        return -1;  // Out-of-bounds-Schreiben ablehnen
    }
    log_buffer[index] = value;
    return 0;
}

// SICHER: Niemals Benutzereingabe als Format-String verwenden
void log_message_safe(const char *user_input) {
    // Format-Specifier verwenden - Benutzereingabe kann kein %n einschleusen
    printf("%s", user_input);
}

// SICHER: Grenzengeprüfte Heap-Kopie
void heap_copy_safe(const char *user_data, size_t len) {
    const size_t BUFFER_SIZE = 32;

    if (len > BUFFER_SIZE) {
        len = BUFFER_SIZE;  // Auf Puffergröße kürzen
    }

    char *buf = malloc(BUFFER_SIZE);
    if (!buf) return;

    memcpy(buf, user_data, len);
    // Puffer verwenden...
    free(buf);
}

Ausgenutzt in der Praxis

GhostWrite CPU-Schwachstelle (T-Head RISC-V, 2024)

Die T-Head XuanTie C910 und C920 RISC-V CPUs enthalten Instruktionen, die unprivilegierten Angreifern erlauben, an beliebige physische Speicherstellen zu schreiben. Diese Hardware-Schwachstelle ermöglicht vollständige Systemkompromittierung aus dem Userspace.

VMware ESXi Sandbox-Escape (VMware, 2024)

CVE-2024-22252 ist eine beliebige-Schreib-Schwachstelle in VMware ESXi, bei der ein bösartiger Akteur mit VMX-Prozess-Privilegien ein beliebiges Kernel-Schreiben auslösen kann, was zu VM-Escape führt.

Adobe Substance3D Mehrfache WWW (Adobe, 2024)

Mehrere Adobe Substance3D-Produkte (Painter, Stager) enthielten Write-what-where-Schwachstellen, die beliebige Code-Ausführung durch bösartige Dateien ermöglichten.


Tools zum Testen/Ausnutzen

  • pwntools — CTF-Framework mit Utilities zum Erstellen von Write-what-where-Exploits.

  • ROPgadget — Gadgets finden zur Verkettung mit Schreib-Primitiven.

  • one_gadget — Single-Shot-Gadgets finden für Exploitation nach Erreichen von Write-what-where.


CVE-Beispiele

  • CVE-2024-22252 — VMware ESXi beliebiges Schreiben ermöglicht VM-Escape.

  • CVE-2024-41867 — Adobe Substance3D Stager Write-what-where-Schwachstelle.

  • CVE-2024-20767 — Adobe ColdFusion beliebige Schreib-Schwachstelle.


Referenzen

  1. MITRE. "CWE-123: Write-what-where Condition." https://cwe.mitre.org/data/definitions/123.html

  2. Phrack. "Advanced Doug Lea's malloc exploits." http://phrack.org/issues/61/6.html