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:

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.
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.
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 und verschiedene -Module im Fokus stehen.

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:

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).
Exportieren von Konfigurationsvariablen (wie PROJECT, HARNESS, LABEL, Pfade zu projektspezifischen Patches und Ausgabeverzeichnisse).
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.

# From the project root directory:
./submission/part_1/run.w_corpus.sh  # Run input-fuzzer with default seed corpus
./submission/part_1/run.wo_corpus.sh # Run input-fuzzer without seed corpus

run.w_corpus.sh verwendet das Standard-tmux-Buildverhalten in Bezug auf Seeds. run.wo_corpus.sh wendet submission/part_1/remove_seed_corpus.patch (über sein lokales oss-fuzz.diff, das auf diesen Patch verweist oder dessen Änderungen integriert) auf oss-fuzz/projects/tmux/build.sh an, um sicherzustellen, dass kein anfängliches Seed-Korpus verwendet wird. Abdeckungsberichte werden nach submission/part_1/report/w_corpus/ and submission/part_1/report/wo_corpus/ und submission/part_1/report/wo_corpus/ exportiert.

2. Teil 3: Fuzzer-Verbesserungen (input-fuzzer)

Verbesserung 1 (argument-fuzzer): Zielt auf arguments.c.

# From the project root directory:
./submission/part_3/improve1/run.improve1.sh

Verbesserung 2 (cmd-fuzzer): Zielt auf cmd-parse.c und die Befehlsausführung.
```
# From the project root directory:
./submission/part_3/improve2/run.improve2.sh
```

Jedes run.improveX.sh-Skript wendet sein lokales oss-fuzz.diff an und setzt PROJECT_PATCH_FILE auf sein lokales project.diff (das den neuen Fuzzer-Code zu tmux hinzufügt und Makefile.am aktualisiert). Abdeckungsberichte werden in die jeweiligen Verzeichnisse submission/part_3/improveX/coverage_improveX/ exportiert. Das Verzeichnis submission/part_3/coverage_noimprove/ enthält die Basisabdeckung aus Teil 1 zum Vergleich.

3. Teil 4: Reproduktion des CVE-2020-27347-PoC

# From the project root directory:
./submission/part_4/run.poc.sh

Dieses Skript erstellt ein dediziertes Docker-Image (aus submission/part_4/environment/Dockerfile) und testet tmux 3.1b (verwundbar) gegen den gepatchten Commit a868bac.

Wichtige Ergebnisse und Befunde

(Ausführliche Erklärungen, Abbildungen und Tabellen finden sich im vollständigen report.pdf)

Teil 1 (Basislinie - input-fuzzer)

Mit Standard-Seed-Korpus: 14,00 % Zeilenabdeckung (7281/51997 Zeilen), 24,44 % Funktionsabdeckung.
Ohne Seed-Korpus: 13,94 % Zeilenabdeckung (7248/51997 Zeilen), 24,31 % Funktionsabdeckung.
Die Auswirkung des anfänglichen Seed-Korpus war für den bestehenden input-fuzzer gering.
Bedeutende Teile von tmux, insbesondere Argumentparsing (arguments.c), Befehls-/Ausführungslogik (cmd-parse.c, cmd-*.c) sowie Client-/Serverlogik (client.c, server.c), waren weitgehend nicht abgedeckt (z. B. arguments.c mit ~5,8 % Zeilenabdeckung).

Teil 3 (Fuzzer-Verbesserungen)

argument-fuzzer (zielt auf arguments.c): Erreichte 66,62 % Zeilenabdeckung für arguments.c, eine erhebliche Steigerung gegenüber der Basislinie von ~5,8 %.
cmd-fuzzer (zielt auf Befehls- & Ausführungslogik): Erhöhte die Zeilenabdeckung für cmd-parse.c auf 42,58 % (von ~27 %) und die Funktionsabdeckung auf 77,78 %.
Die arguments.c-Abdeckung stieg durch diesen Fuzzer ebenfalls auf 45,54 %.
cmd.c erreichte 39,14 % Zeilenabdeckung.
Erzielte neue oder deutlich verbesserte Abdeckung in verschiedenen cmd-*.c-Modulen (z. B. cmd-bind-key.c, cmd-set-options.c auf 50 % Funktionsabdeckung) sowie in Schlüsselbehandlungsroutinen (key-string.c auf 30 % Zeilenabdeckung, key-bindings.c auf 6,05 % Zeilenabdeckung).

Teil 4 (CVE-2020-27347-Analyse)

CVE-2020-27347 (Stack-Pufferüberlauf beim Parsen von SGR-Escape-Sequenzen) wurde auf tmux 3.1b (Commit 6a33a12) mit dem Payload \033[::::::7::1:2:3::5:6:7:m erfolgreich reproduziert.
Es wurde bestätigt, dass der tmux-Commit a868bac (der den Fix enthält und zu Version 3.1c führt) nicht für den Crash anfällig war.
Die Schwachstelle, die durch das Schreiben einer präparierten Sequenz in ein Pane-TTY ausnutzbar ist, führt zu Denial-of-Service und birgt Potenzial für beliebige Codeausführung (Arbitrary Code Execution). Sie wird mit hohem Schweregrad bewertet (CVSS 7.8).

Herausforderungen

Die Sicherstellung eines korrekten tmux-Starts in einer skriptbasierten Docker-Umgebung, insbesondere die Vermeidung von „not a terminal“-Fehlern, erforderte die Verwendung abgekoppelter (detached) Sitzungen für den CVE-PoC.
Die Verwaltung des Git-Zustands (Sicherstellung vollständiger Klone und sauberer Resets vor dem Anwenden von Patches) über verschiedene Testszenarien hinweg war entscheidend für reproduzierbare Builds bestimmter tmux-Versionen.
Die Entwicklung effektiver neuer Fuzzing-Harnesses (argument-fuzzer, cmd-fuzzer) erforderte ein gutes Verständnis der internen Argument- und Befehlsverarbeitungslogik von tmux, um gezielt bestimmte ungetestete Codepfade anzusteuern.

Zukünftige Arbeiten

Den cmd-fuzzer weiter verbessern, um ein breiteres Spektrum an cmd-*.c-Modulen abzudecken, insbesondere solche, die komplexe Zustandsinteraktionen wie Fenster-, Layout- oder Pane-Manipulationen behandeln.
Fuzzing-Strategien für das Client-Server-Kommunikationsprotokoll von tmux untersuchen, möglicherweise unter Einbeziehung eines komplexeren Environment-Mockings.
Den Einsatz von strukturbewusstem Fuzzing für die tmux-Befehlssprache erkunden, möglicherweise durch Nutzung der Grammatikdefinitionen aus cmd-parse.y, um syntaktisch gültigere und komplexere Befehlssequenzen zu erzeugen.

Nützliche Links

tmux-Projekt
OSS-Fuzz
CVE-2020-27347
Projektbericht als PDF (Pfad relativ zum Projektstamm)

tmux-fuzzing

Beliebteste