Fuzzing-Labor: Verbesserung des Fuzzings für tmux

Software Security @ EPFL, Frühjahr 2025

Zusammenfassung

In diesem Labor haben wir die Fuzzing-Bemühungen für den Terminal-Multiplexer tmux innerhalb von Googles OSS-Fuzz-Infrastruktur verbessert. Zunächst erstellten wir eine Basislinie, indem wir die Zeilenabdeckung des bestehenden input-fuzzer-Harnesses bewerteten – sowohl mit als auch ohne das bereitgestellte Seed-Korpus – und stellten eine vergleichbare anfängliche Abdeckung fest. Anschließend identifizierten wir zwei bedeutende Codebereiche in tmux, die vom Basis-Fuzzer nur unzureichend abgedeckt wurden. Um diese Abdeckungslücken zu schließen, entwickelten und evaluierten wir zwei neue gezielte Fuzzing-Harnesses, cmd-fuzzer und argument-fuzzer, und demonstrierten deren Fähigkeit, die Abdeckung in diesen zuvor unzureichend getesteten Bereichen zu verbessern. Da diese Fuzzing-Verbesserungen im Projektzeitraum keine neuen kritischen Schwachstellen aufdeckten, konzentrierte sich unsere Crash-Analyse auf eine bekannte historische Schwachstelle. Wir entwickelten einen Proof-of-Concept (PoC) für CVE-2020-27347 (einen stack-basierten Pufferüberlauf), analysierten dessen Grundursache, diskutierten den implementierten Fix und bewerteten seine sicherheitstechnischen Auswirkungen.

Projektübersicht und Ziele

Dieses Projekt zielte darauf ab, Fuzzing-Techniken auf den Open-Source-Terminal-Multiplexer tmux anzuwenden und zu verbessern, wobei das OSS-Fuzz-Framework verwendet wurde. Das Projekt umfasste mehrere wichtige Phasen:

1. Basislinien-Bewertung (Teil 1):

   • Den bestehenden input-fuzzer-Harness für tmux verstehen und bewerten.
   • Seine Codeabdeckung beim Lauf mit dem Standard-Seed-Korpus im Vergleich zu einem leeren Seed-Korpus vergleichen.

2. Abdeckungslücken-Analyse (Teil 2):

   • Abdeckungsberichte aus Teil 1 analysieren, um bedeutende Codebereiche in tmux zu identifizieren, die vom input-fuzzer nicht ausreichend abgedeckt werden.
   • Fokus auf Argumentparsing (arguments.c) und Befehls-/Ausführungslogik (cmd-parse.c, cmd-*.c-Module) als Schlüsselbereiche für Verbesserungen.

3. Fuzzer-Verbesserung (Teil 3):

   • Zwei neue, gezielte Fuzzing-Harnesses entwickeln:
     • argument-fuzzer: Speziell entwickelt, um die Befehlszeilen-Argumentparsing-Logik in arguments.c zu testen.
     • cmd-fuzzer: Entwickelt, um die Befehls- und Ausführungspfade zu testen, wobei cmd-parse.c und verschiedene cmd-*.c-Module im Fokus stehen.
   • Die Wirksamkeit dieser neuen Harnesses bewerten, indem ihre erreichte Codeabdeckung gemessen und mit der Basislinie verglichen wird.

4. Crash-Analyse (Teil 4):

   • Da die verbesserten Fuzzer im Projektzeitraum keine neuen kritischen Schwachstellen entdeckten, wurde eine bekannte, bereits bestehende Schwachstelle in tmux (CVE-2020-27347) für eine eingehende Analyse ausgewählt.
   • Dies umfasste die Entwicklung eines Proof of Concept (PoC) zur Reproduktion des Crashes, die Analyse seiner Grundursache, das Verständnis des angewendeten Fixes und die Bewertung seiner sicherheitstechnischen Auswirkungen.

Repository-Struktur

Die finale Abgabe ist wie folgt organisiert (innerhalb des submission/-Verzeichnisses):

submission/
├── README.md                   # This file
├── part_1/                     # Files for Part 1: Baseline Evaluation
│   ├── oss-fuzz.diff           # Diff for removing seed corpus for input-fuzzer
│   ├── project.diff            # (Likely empty or minor for Part 1)
│   ├── remove_seed_corpus.patch # The actual patch file used
│   ├── report/                 # HTML Coverage reports for input-fuzzer
│   │   ├── w_corpus/
│   │   └── wo_corpus/
│   ├── run.w_corpus.sh         # Script to run input-fuzzer with corpus
│   └── run.wo_corpus.sh        # Script to run input-fuzzer without corpus
├── part_3/                     # Files for Part 3: Fuzzer Improvements
│   ├── coverage_noimprove/     # Baseline coverage (e.g., from input-fuzzer without corpus)
│   │   └── ...
│   ├── improve1/               # Improvement 1: argument-fuzzer
│   │   ├── coverage_improve1/  # Coverage report for argument-fuzzer
│   │   ├── oss-fuzz.diff       # OSS-Fuzz config changes for argument-fuzzer
│   │   ├── project.diff        # Tmux changes for argument-fuzzer (e.g., new .cc, Makefile.am)
│   │   └── run.improve1.sh     # Script to run argument-fuzzer
│   └── improve2/               # Improvement 2: cmd-fuzzer
│       ├── coverage_improve2/  # Coverage report for cmd-fuzzer
│       ├── oss-fuzz.diff       # OSS-Fuzz config changes for cmd-fuzzer
│       ├── project.diff        # Tmux changes for cmd-fuzzer
│       └── run.improve2.sh     # Script to run cmd-fuzzer
├── part_4/                     # Files for Part 4: Crash Analysis (CVE-2020-27347)
│   ├── environment/            # Docker environment for PoC
│   │   ├── Dockerfile
│   │   ├── run_tmux_cve_test.sh # Core PoC test logic
│   │   ├── test_fixed.sh
│   │   └── test_vulnerable.sh
│   └── run.poc.sh              # Script to build Docker image and run PoC tests
└── report.pdf                  # The comprehensive project report

(Hinweis: Das scripts/-Verzeichnis mit _run_fuzz_core.sh ist ein Hilfsskript und wäre Teil des Projektstamms, wenn sich dieses README im tatsächlichen Projektstamm neben submission/ befände)

Einrichtung und Verwendung

Alle Fuzzing-Kampagnen und die CVE-PoC-Reproduktion sind darauf ausgelegt, in Docker-Umgebungen ausgeführt zu werden, die durch Shell-Skripte orchestriert werden.

Einrichtung und Verwendung

Alle Fuzzing-Kampagnen und die CVE-PoC-Reproduktion sind darauf ausgelegt, in Docker-Umgebungen ausgeführt zu werden, die durch Shell-Skripte orchestriert werden.

Voraussetzungen:

• Docker installiert und auf einem Unix-ähnlichen System lauffähig.
• bash-Shell und git-Client.
• SSH-Schlüssel müssen für [email protected] konfiguriert sein, falls die Skripte oss-fuzz klonen müssen (sie versuchen zu klonen, wenn oss-fuzz/ im Projektstamm nicht gefunden wird). Alternativ kann https://github.com/google/oss-fuzz.git vorab in den Projektstamm geklont werden.

Allgemeine Skriptarchitektur: Das Projekt verwendet ein zentrales Kernskript, scripts/_run_fuzz_core.sh (nicht im submission/-Verzeichnis enthalten, aber Teil der Gesamtprojektstruktur, die dieses README voraussetzt). Die einzelnen Runner-Skripte in submission/part_1/, submission/part_3/improve1/, submission/part_3/improve2/ und submission/part_4/ sind verantwortlich für:

1. Einrichten der spezifischen Testumgebung durch Anwenden von laufspezifischen oss-fuzz.diff-Patches auf einen sauberen Checkout des oss-fuzz-Repositorys (erwartet unter ../../oss-fuzz relativ zu den meisten Runner-Skripten).
2. Exportieren von Konfigurationsvariablen (wie PROJECT, HARNESS, LABEL, Pfade zu projektspezifischen Patches und Ausgabeverzeichnisse).
3. Aufrufen des _run_fuzz_core.sh-Skripts, das dann Folgendes übernimmt:
   • Anwenden eines optionalen projektweiten Patches (z. B. um neue Fuzzer-Quellen zu tmux hinzuzufügen).
   • Erstellen des OSS-Fuzz-Docker-Images (falls per Flag gesetzt).
   • Erstellen des/der angegebenen Fuzzer(s) mit dem gewählten Sanitizer.
   • Ausführen des Fuzzers für die konfigurierte Dauer (typischerweise 4 Stunden).
   • Generieren und Exportieren von Korpus- und HTML-Abdeckungsberichten an die vorgesehenen Orte innerhalb der submission/-Verzeichnisstruktur.

Ausführen der Skripte: Es wird allgemein empfohlen, die Runner-Skripte aus dem Projektstammverzeichnis auszuführen, um eine korrekte relative Pfadauflösung für oss-fuzz/ und die Ausgabeverzeichnisse sicherzustellen.

1. Teil 1: Basislinien-Bewertung (input-fuzzer) Diese Skripte bewerten den bestehenden input-fuzzer für tmux.