MongoDB-Kompressionsleck-Labor (Sicher, lehrreich)

Referenz-CVE: CVE-2025-14847

Dieses Repository ist ein Lehrlabor, das das Konzept hinter einer Klasse von Problemen demonstriert, die oft als „Kompressions-Framing / Größenmetadaten-Speicheroffenlegung“ in Datenbank-Drahtprotokollen beschrieben werden.

Es wurde geschrieben, um das defensive Verständnis zu fördern: wie MongoDB-Netzwerkkompression ausgehandelt und geframet wird, warum Größenfelder wichtig sind und wie robuste Parser unbeabsichtigte Speicherexposition verhindern.

Hinweis zur CVE-Referenz: Dieses Labor ist um die Idee herum aufgebaut, die als CVE-2025-14847 referenziert wird. Dieses Repo validiert, reproduziert oder exploitiert keinen spezifischen Anbieterfehler und behauptet nicht, dass eine bestimmte MongoDB-Version betroffen ist. Es konzentriert sich auf die allgemeine Fehlerart (nicht übereinstimmende Größenmetadaten um komprimierte Nutzdaten) und die Gegenmaßnahmen.

Versionsstatus (anfällig vs. gepatcht)

Dieses Repository enthält keine (und sollte nicht verwendet werden als) Beweise dafür, welche MongoDB-Versionen für eine bestimmte CVE anfällig oder gepatcht sind.

Um „anfällige“ vs. „gepatchte“ Versionen korrekt für einen Bericht zu dokumentieren, verwenden Sie eine offizielle Anbieterberatung / Release-Notizen für die CVE und zitieren Sie diese.

Praktische Schritte zur Überprüfung, was Sie ausführen:

• Docker-Container-Version:
  • docker compose exec mongodb mongod --version
  • oder docker compose exec mongodb mongosh --quiet --eval "db.version()"
• Host-Installationsversion:
  • mongod --version
  • mongosh --quiet --eval "db.version()"

Wenn Sie den von Ihnen verwendeten Advisory-Link teilen, kann ich eine saubere Tabelle „Betroffen / Beheben“ in der README formatieren, ohne zu raten.

Was die Schwachstelle ist (konzeptionell)

Dieses Labor veranschaulicht eine Fehlerart des Kompressions-Framing / Größenmetadaten-Mismatch:

• MongoDB-Nachrichten sind längenpräfixiert. Bei Netzwerkkompression fügt ein OP_COMPRESSED-Envelope weitere Größenfelder hinzu (äußere Nachrichtenlänge, deklarierte unkomprimierte Größe und die Länge der inneren Nachricht).
• Wenn eine Implementierung diesen Größenfeldern ohne strenge Validierung vertraut, kann sie Puffer während der Dekompression oder des Parsens falsch behandeln.
• In fehlerhaften Implementierungen kann dies zu Out-of-Bounds-Reads oder zur Rückgabe nicht initialisierter Pufferbytes führen, was eine Art der „Speicheroffenlegung“ darstellt.

Siehe protocol_overview.md für die detaillierte Framing-Durchlauf.

Ethische Hinweise

• Dieses Projekt ist von Natur aus nicht ausnutzbar.
• Es enthält keine waffenfähige Logik, Exploit-Code oder Techniken, die darauf abzielen, Systeme zu kompromittieren.
• Es sollte nur gegen den hier bereitgestellten lokalen Docker-Container ausgeführt werden.
• Richten Sie diesen Code nicht gegen Systeme, die Sie nicht besitzen oder für die Sie keine ausdrückliche Erlaubnis zum Testen haben.

Lernziele

Am Ende des Labors sollten Sie in der Lage sein:

• Erklären, wie das Drahtprotokoll-Framing von MongoDB auf hoher Ebene funktioniert.
• Beschreiben, wie zlib-Netzwerkkompression ausgehandelt und angewendet wird.
• Verstehen, wie fehlerhafte Längen-/Größenmetadaten konzeptionell zu Speicherexposition in einer fehlerhaften Implementierung führen könnten.
• Praktische Gegenmaßnahmen identifizieren: Patchen, Härten der Konfiguration und Netzwerkerkennung.

Was dieses Repo tut (und nicht tut)

Es tut:

• Starten Sie MongoDB in Docker mit aktivierter zlib-Kompression.
• Verwenden Sie einen kleinen, originären Python-Client, um:
  • Senden Sie ein unkomprimiertes hello einschließlich compression: ["zlib"]
  • Senden Sie eine korrekt geframte OP_COMPRESSED-Nachricht mit zlib
  • Protokollieren Sie unkomprimierte vs. komprimierte Größen und eine Zusammenfassung der Serverantworten
• Fügen Sie eine lokale „Spielzeugparser“-Demonstration hinzu, die zeigt, wie ein defensiver Parser nicht übereinstimmende Größenmetadaten ablehnt.

Es tut NICHT:

• Bösartige Pakete für die tatsächliche Ausnutzung erstellen.
• Authentifizierungsumgehung versuchen.
• Versuchen, beliebigen Speicher zu lesen.

Repository-Inhalte

• docker-compose.yml – Führt einen MongoDB-Container mit aktivierter zlib-Kompression und nur localhost-Exposition aus.
• protocol_overview.md – Drahtprotokoll + BSON + Kompressionsworkflow + konzeptionelle Schwachstellenerklärung.
• mitigation.md – Verteidigungsleitfaden: Patch-, Konfigurations- und Erkennungsideen.
• lab_probe.py – Originalsonde, die Kompression aushandelt und Nachrichtengrößen sicher protokolliert.

So führen Sie das Labor sicher aus

1) Voraussetzungen

• Docker Desktop (oder kompatible Docker-Engine)
• Python 3.10+ (empfohlen)

2) MongoDB starten

Aus diesem Repo-Verzeichnis:

docker compose up -d

Bestätigen Sie, dass es läuft:

docker compose ps

3) Die Sonde ausführen

python .\lab_probe.py

Erwartete Ausgabe:

• Gibt ausgehandelte Kompressoren aus dem ersten hello aus
• Gibt Anforderungs-/Antwortgrößen aus
• Sendet ein komprimiertes hello und protokolliert sowohl komprimierte als auch dekomprimierte Nachrichtengrößen

4) Die Spielzeugdemo ausführen (kein Netzwerk)

python .\lab_probe.py --toy-demo

Dies führt nur lokale Parsing-Prüfungen durch, um zu veranschaulichen, warum Größenvalidierung wichtig ist.

5) Herunterfahren

docker compose down

Sicherheitshinweise

• Der Container ist an 127.0.0.1:27017 auf dem Host gebunden.
• Kein Exploit-Verhalten ist vorhanden.
• Die Sonde erzwingt konservative Grenzen (z. B. maximale Nachrichtengröße) und validiert alle Längenfelder.