Laboratorio di Fuzzing: Migliorare il Fuzzing per tmux

Software Security @ EPFL, Primavera 2025

Abstract

In questo laboratorio, abbiamo potenziato le attività di fuzzing per il multiplexer di terminale tmux nell'infrastruttura OSS-Fuzz di Google. Abbiamo innanzitutto stabilito una baseline valutando la copertura delle righe dell'harness input-fuzzer esistente, sia con che senza il suo corpus di seed fornito, riscontrando una copertura iniziale comparabile. Successivamente, abbiamo identificato due regioni di codice significative in tmux scarsamente esercitate dal fuzzer di baseline. Per colmare queste lacune di copertura, abbiamo sviluppato e valutato due nuovi harness di fuzzing mirati, cmd-fuzzer e argument-fuzzer, dimostrando la loro capacità di migliorare la copertura in queste aree precedentemente poco testate. Poiché questi miglioramenti al fuzzing non hanno scoperto nuove vulnerabilità critiche entro i tempi del progetto, la nostra analisi dei crash si è concentrata su una vulnerabilità storica nota. Abbiamo sviluppato una prova di concetto (PoC) per CVE-2020-27347 (un buffer overflow basato su stack), analizzato la sua causa principale, discusso la correzione implementata e valutato le sue implicazioni per la sicurezza.

Panoramica del Progetto e Obiettivi

Questo progetto mirava ad applicare e migliorare le tecniche di fuzzing sul multiplexer di terminale open-source tmux, utilizzando il framework OSS-Fuzz. Il progetto ha compreso diverse fasi chiave:

1. Valutazione della Baseline (Parte 1):

   • Comprendere e valutare l'harness input-fuzzer esistente per tmux.
   • Confrontare le sue prestazioni di copertura del codice quando eseguito con il suo corpus di seed predefinito rispetto a un corpus di seed vuoto.

2. Analisi delle Lacune di Copertura (Parte 2):

   • Analizzare i rapporti di copertura della Parte 1 per identificare regioni di codice significative in tmux non adeguatamente esercitate dall'input-fuzzer.
   • Concentrarsi sul parsing degli argomenti (arguments.c) e sulla logica di parsing/esecuzione dei comandi (moduli cmd-parse.c, cmd-*.c) come aree chiave per il miglioramento.

3. Miglioramento del Fuzzer (Parte 3):

   • Sviluppare due nuovi harness di fuzzing mirati:
     • argument-fuzzer: progettato specificamente per testare la logica di parsing degli argomenti da riga di comando in arguments.c.
     • cmd-fuzzer: progettato per testare i percorsi di parsing ed esecuzione dei comandi, mirando a cmd-parse.c e a vari moduli cmd-*.c.
   • Valutare l'efficacia di questi nuovi harness misurando la copertura del codice raggiunta e confrontandola con la baseline.

4. Analisi dei Crash (Parte 4):

   • Poiché i fuzzer migliorati non hanno scoperto nuove vulnerabilità critiche entro i tempi del progetto, è stata selezionata per un'analisi approfondita una vulnerabilità nota e preesistente in tmux (CVE-2020-27347).
   • Ciò ha comportato lo sviluppo di una Proof of Concept (PoC) per riprodurre il crash, l'analisi della sua causa principale, la comprensione della correzione applicata e la valutazione delle sue implicazioni per la sicurezza.

Struttura del Repository

La consegna finale è organizzata come segue (all'interno della directory submission/):

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

(Nota: la directory scripts/ contenente _run_fuzz_core.sh è un ausilio e farebbe parte della radice se questo README si trovasse nella radice effettiva del progetto, accanto a submission/)

Setup e Utilizzo

Tutte le campagne di fuzzing e la riproduzione della PoC della CVE sono progettate per essere eseguite all'interno di ambienti Docker orchestrati da script di shell.

Setup e Utilizzo

Tutte le campagne di fuzzing e la riproduzione della PoC della CVE sono progettate per essere eseguite all'interno di ambienti Docker orchestrati da script di shell.

Prerequisiti:

• Docker installato e in esecuzione su un sistema di tipo Unix.
• Shell bash e client git.
• Chiavi SSH configurate per [email protected] se gli script devono clonare oss-fuzz (provano a clonarlo se oss-fuzz/ non viene trovato nella radice del progetto). In alternativa, puoi pre-clonare https://github.com/google/oss-fuzz.git nella radice del progetto.

Architettura Generale degli Script: Il progetto utilizza uno script core centralizzato, scripts/_run_fuzz_core.sh (non incluso nella directory submission/ ma parte della struttura complessiva del progetto presupposta da questo README). Gli script runner individuali situati in submission/part_1/, submission/part_3/improve1/, submission/part_3/improve2/ e submission/part_4/ sono responsabili di:

1. Configurare l'ambiente di test specifico applicando le patch oss-fuzz.diff specifiche dell'esecuzione a un checkout pulito del repository oss-fuzz (previsto in ../../oss-fuzz rispetto alla maggior parte degli script runner).
2. Esportare le variabili di configurazione (come PROJECT, HARNESS, LABEL, i percorsi delle patch specifiche del progetto e le directory di output).
3. Richiamare lo script _run_fuzz_core.sh, che si occupa quindi di:
   • Applicare una patch opzionale a livello di progetto (ad es. per aggiungere nuovi sorgenti di fuzzer a tmux).
   • Costruire l'immagine Docker di OSS-Fuzz (se indicato).
   • Compilare il o i fuzzer specificati con il sanitizer scelto.
   • Eseguire il fuzzer per la durata configurata (in genere 4 ore).
   • Generare ed esportare il corpus e i rapporti di copertura HTML nelle posizioni designate all'interno della struttura della directory submission/.

Esecuzione degli Script: In generale, si consiglia di eseguire gli script runner dalla directory radice del progetto per garantire una corretta risoluzione dei percorsi relativi per oss-fuzz/ e le directory di output.

1. Parte 1: Valutazione della Baseline (input-fuzzer) Questi script valutano l'input-fuzzer esistente per tmux.