Laboratoire de Fuzzing : Améliorer le fuzzing pour tmux

Sécurité logicielle @ EPFL, Printemps 2025

Résumé

Dans ce laboratoire, nous avons amélioré les efforts de fuzzing pour le multiplexeur de terminaux tmux au sein de l'infrastructure OSS-Fuzz de Google. Nous avons d'abord établi une référence en évaluant la couverture de ligne du harnais input-fuzzer existant, avec et sans son corpus de graines fourni, en notant une couverture initiale comparable. Ensuite, nous avons identifié deux régions de code significatives dans tmux mal exercées par le fuzzer de référence. Pour combler ces lacunes de couverture, nous avons développé et évalué deux nouveaux harnais de fuzzing ciblés, cmd-fuzzer et argument-fuzzer, démontrant leur capacité à améliorer la couverture dans ces zones auparavant sous-testées. Ces améliorations de fuzzing n'ayant pas découvert de nouvelles vulnérabilités critiques dans le délai imparti du projet, notre analyse des crashes s'est concentrée sur une vulnérabilité historique connue. Nous avons développé une preuve de concept (PoC) pour CVE-2020-27347 (un débordement de tampon basé sur la pile), analysé sa cause racine, discuté du correctif appliqué et évalué ses implications en matière de sécurité.

Aperçu du projet et objectifs

Ce projet visait à appliquer et améliorer les techniques de fuzzing sur le multiplexeur de terminaux open-source tmux, en utilisant le framework OSS-Fuzz. Le projet comprenait plusieurs étapes clés :

1. Évaluation de base (Partie 1) :

   • Comprendre et évaluer le harnais input-fuzzer existant pour tmux.
   • Comparer ses performances de couverture de code lorsqu'il est exécuté avec son corpus de graines par défaut par rapport à un corpus de graines vide.

2. Analyse des lacunes de couverture (Partie 2) :

   • Analyser les rapports de couverture de la Partie 1 pour identifier les régions de code significatives dans tmux qui ne sont pas suffisamment exercées par le input-fuzzer.
   • Se concentrer sur l'analyse des arguments (arguments.c) et la logique d'analyse et d'exécution des commandes (cmd-parse.c, modules cmd-*.c) comme domaines clés d'amélioration.

3. Amélioration du fuzzer (Partie 3) :

   • Développer deux nouveaux harnais de fuzzing ciblés :
     • argument-fuzzer : Conçu spécifiquement pour tester la logique d'analyse des arguments en ligne de commande dans arguments.c.
     • cmd-fuzzer : Conçu pour tester les chemins d'analyse et d'exécution des commandes, ciblant cmd-parse.c et divers modules cmd-*.c.
   • Évaluer l'efficacité de ces nouveaux harnais en mesurant leur couverture de code atteinte et en la comparant à la référence.

4. Analyse de crash (Partie 4) :

   • Comme aucune nouvelle vulnérabilité critique n'a été découverte par les fuzzers améliorés dans le délai imparti du projet, une vulnérabilité connue préexistante dans tmux (CVE-2020-27347) a été sélectionnée pour une analyse approfondie.
   • Cela a impliqué le développement d'une preuve de concept (PoC) pour reproduire le crash, l'analyse de sa cause racine, la compréhension du correctif appliqué et l'évaluation de ses implications en matière de sécurité.

Structure du dépôt

La soumission finale est organisée comme suit (dans le répertoire submission/) :

submission/
├── README.md                   # Ce fichier
├── part_1/                     # Fichiers pour la Partie 1 : Évaluation de base
│   ├── oss-fuzz.diff           # Diff pour supprimer le corpus de graines pour input-fuzzer
│   ├── project.diff            # (Probablement vide ou mineur pour la Partie 1)
│   ├── remove_seed_corpus.patch # Le fichier de patch effectif utilisé
│   ├── report/                 # Rapports de couverture HTML pour input-fuzzer
│   │   ├── w_corpus/
│   │   └── wo_corpus/
│   ├── run.w_corpus.sh         # Script pour exécuter input-fuzzer avec corpus
│   └── run.wo_corpus.sh        # Script pour exécuter input-fuzzer sans corpus
├── part_3/                     # Fichiers pour la Partie 3 : Améliorations du fuzzer
│   ├── coverage_noimprove/     # Couverture de référence (par ex., depuis input-fuzzer sans corpus)
│   │   └── ...
│   ├── improve1/               # Amélioration 1 : argument-fuzzer
│   │   ├── coverage_improve1/  # Rapport de couverture pour argument-fuzzer
│   │   ├── oss-fuzz.diff       # Changements de configuration OSS-Fuzz pour argument-fuzzer
│   │   ├── project.diff        # Changements Tmux pour argument-fuzzer (par ex., nouveau .cc, Makefile.am)
│   │   └── run.improve1.sh     # Script pour exécuter argument-fuzzer
│   └── improve2/               # Amélioration 2 : cmd-fuzzer
│       ├── coverage_improve2/  # Rapport de couverture pour cmd-fuzzer
│       ├── oss-fuzz.diff       # Changements de configuration OSS-Fuzz pour cmd-fuzzer
│       ├── project.diff        # Changements Tmux pour cmd-fuzzer
│       └── run.improve2.sh     # Script pour exécuter cmd-fuzzer
├── part_4/                     # Fichiers pour la Partie 4 : Analyse de crash (CVE-2020-27347)
│   ├── environment/            # Environnement Docker pour PoC
│   │   ├── Dockerfile
│   │   ├── run_tmux_cve_test.sh # Logique de test PoC principale
│   │   ├── test_fixed.sh
│   │   └── test_vulnerable.sh
│   └── run.poc.sh              # Script pour construire l'image Docker et exécuter les tests PoC
└── report.pdf                  # Le rapport de projet complet

(Note : Le répertoire scripts/ contenant _run_fuzz_core.sh est un helper et ferait partie de la racine si ce README se trouve à la vraie racine du projet aux côtés de submission/)

Configuration et utilisation

Toutes les campagnes de fuzzing et la reproduction du PoC CVE sont conçues pour être exécutées dans des environnements Docker orchestrés par des scripts shell.

Configuration et utilisation

Toutes les campagnes de fuzzing et la reproduction du PoC CVE sont conçues pour être exécutées dans des environnements Docker orchestrés par des scripts shell.

Prérequis :

• Docker installé et en cours d'exécution sur un système de type Unix.
• Shell bash et client git.
• Clés SSH configurées pour [email protected] si les scripts doivent cloner oss-fuzz (ils tentent de cloner si oss-fuzz/ n'est pas trouvé à la racine du projet). Alternativement, vous pouvez pré-cloner https://github.com/google/oss-fuzz.git dans la racine du projet.

Architecture générale des scripts : Le projet utilise un script centralisé, scripts/_run_fuzz_core.sh (non inclus dans le répertoire submission/ mais faisant partie de la structure globale du projet supposée par ce README). Les scripts d'exécution individuels situés dans submission/part_1/, submission/part_3/improve1/, submission/part_3/improve2/ et submission/part_4/ sont responsables de :

1. Configurer l'environnement de test spécifique en appliquant des correctifs oss-fuzz.diff spécifiques à l'exécution sur un checkout propre du dépôt oss-fuzz (attendu à ../../oss-fuzz par rapport à la plupart des scripts d'exécution).
2. Exporter les variables de configuration (comme PROJECT, HARNESS, LABEL, les chemins vers les correctifs spécifiques au projet et les répertoires de sortie).
3. Invoquer le script _run_fuzz_core.sh, qui gère ensuite :
   • L'application d'un correctif optionnel au niveau du projet (par exemple, pour ajouter de nouvelles sources de fuzzer à tmux).
   • La construction de l'image Docker OSS-Fuzz (si signalé).
   • La construction du ou des fuzzers spécifiés avec le sanitizer choisi.
   • L'exécution du fuzzer pendant la durée configurée (généralement 4 heures).
   • La génération et l'exportation du corpus et des rapports de couverture HTML vers les emplacements désignés dans la structure du répertoire submission/.