lucadibello/tmux-fuzzingFuzzing amélioré pour tmux avec OSS-Fuzz. Inclut des harnais personnalisés `cmd-fuzzer` et `argument-fuzzer` pour une meilleure couverture de code et un PoC pour `CVE-2020-27347`.
Sécurité logicielle @ EPFL, Printemps 2025
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é.
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 :
Évaluation de base (Partie 1) :
input-fuzzer existant pour tmux.Analyse des lacunes de couverture (Partie 2) :
tmux qui ne sont pas suffisamment exercées par le input-fuzzer.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.Amélioration du fuzzer (Partie 3) :
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 et divers modules .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/)
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.
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 :
bash et client git.[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 :
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).PROJECT, HARNESS, LABEL, les chemins vers les correctifs spécifiques au projet et les répertoires de sortie)._run_fuzz_core.sh, qui gère ensuite :
tmux).submission/.Exécution des scripts :
Il est généralement recommandé d'exécuter les scripts d'exécution depuis le répertoire racine du projet pour garantir une résolution correcte des chemins relatifs pour oss-fuzz/ et les répertoires de sortie.
1. Partie 1 : Évaluation de base (input-fuzzer)
Ces scripts évaluent le input-fuzzer existant pour tmux.
# Depuis le répertoire racine du projet :
./submission/part_1/run.w_corpus.sh # Exécuter input-fuzzer avec le corpus de graines par défaut
./submission/part_1/run.wo_corpus.sh # Exécuter input-fuzzer sans corpus de graines
run.w_corpus.sh utilise le comportement par défaut de tmux concernant les graines.
run.wo_corpus.sh applique submission/part_1/remove_seed_corpus.patch (via son oss-fuzz.diff local qui ferait référence à ce correctif ou intégrerait ses modifications) au oss-fuzz/projects/tmux/build.sh pour garantir qu'aucun corpus de graines initial n'est utilisé. Les rapports de couverture sont exportés vers submission/part_1/report/w_corpus/ et submission/part_1/report/wo_corpus/ respectivement.
2. Partie 3 : Améliorations du fuzzer (input-fuzzer)
Amélioration 1 (argument-fuzzer) : Cible arguments.c.
# Depuis le répertoire racine du projet :
./submission/part_3/improve1/run.improve1.sh
Amélioration 2 (cmd-fuzzer) : Cible cmd-parse.c et l'exécution des commandes.
# Depuis le répertoire racine du projet :
./submission/part_3/improve2/run.improve2.sh
Chaque script run.improveX.sh applique son oss-fuzz.diff local et définit PROJECT_PATCH_FILE vers son project.diff local (qui ajoute le nouveau code du fuzzer à tmux et met à jour Makefile.am). Les rapports de couverture sont exportés vers les répertoires respectifs submission/part_3/improveX/coverage_improveX/. Le répertoire submission/part_3/coverage_noimprove/ contient la couverture de référence de la Partie 1 pour comparaison.
# Depuis le répertoire racine du projet :
./submission/part_4/run.poc.sh
Ce script construit une image Docker dédiée (à partir de submission/part_4/environment/Dockerfile) et teste tmux 3.1b (vulnérable) par rapport au commit corrigé a868bac.
(Des explications détaillées, des figures et des tableaux se trouvent dans le fichier report.pdf complet)
input-fuzzer existant.arguments.c), l'analyse/exécution des commandes (cmd-parse.c, cmd-*.c), et la logique client/serveur (client.c, server.c), étaient largement inexploitées (par exemple, arguments.c à ~5,8 % de couverture de ligne).argument-fuzzer (ciblant arguments.c) : A atteint 66,62 % de couverture de ligne pour arguments.c, une augmentation substantielle par rapport aux ~5,8 % de référence.cmd-fuzzer (ciblant l'analyse et l'exécution des commandes) : A augmenté la couverture de ligne pour cmd-parse.c à 42,58 % (contre ~27 %) et la couverture de fonction à 77,78 %.arguments.c a également augmenté à 45,54 % grâce à ce fuzzer.cmd.c a atteint 39,14 % de couverture de ligne.cmd-*.c (par exemple, cmd-bind-key.c, cmd-set-options.c à 50 % de couverture de fonction) et les routines de gestion des touches (key-string.c à 30 % de couverture de ligne, key-bindings.c à 6,05 % de couverture de ligne).6a33a12) en utilisant la charge utile \033[::::::7::1:2:3::5:6:7:m.a868bac de tmux (qui inclut le correctif et mène à la version 3.1c) n'était pas sensible au crash.argument-fuzzer, cmd-fuzzer) a nécessité une bonne compréhension de la logique interne d'analyse des arguments et des commandes de tmux pour cibler des chemins de code spécifiques non exercés.cmd-fuzzer pour couvrir un plus large éventail de modules cmd-*.c, en particulier ceux traitant d'interactions d'état complexes comme les manipulations de fenêtres, de mise en page ou de volets.cmd-parse.y pour générer des séquences de commandes syntaxiquement valides et plus complexes.cmd-parse.ccmd-*.cAnalyse de crash (Partie 4) :
tmux (CVE-2020-27347) a été sélectionnée pour une analyse approfondie.