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/):

(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.

run.w_corpus.sh usa il comportamento di build predefinito di tmux per quanto riguarda i seed. run.wo_corpus.sh applica submission/part_1/remove_seed_corpus.patch (tramite il suo oss-fuzz.diff locale, che farebbe riferimento a questa patch o ne integrerebbe le modifiche) a oss-fuzz/projects/tmux/build.sh per garantire che non venga utilizzato alcun corpus di seed iniziale. I rapporti di copertura vengono esportati in submission/part_1/report/w_corpus/ and submission/part_1/report/wo_corpus/ e submission/part_1/report/wo_corpus/ rispettivamente.

2. Parte 3: Miglioramenti del Fuzzer (input-fuzzer)

• Miglioramento 1 (argument-fuzzer): mira a arguments.c.

  root@kitploit:~

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

• Miglioramento 2 (cmd-fuzzer): mira a cmd-parse.c e all'esecuzione dei comandi.

  root@kitploit:~

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

Ogni script run.improveX.sh applica il proprio oss-fuzz.diff locale e imposta PROJECT_PATCH_FILE sul proprio project.diff locale (che aggiunge il nuovo codice del fuzzer a tmux e aggiorna Makefile.am). I rapporti di copertura vengono esportati nelle rispettive directory submission/part_3/improveX/coverage_improveX/. La directory submission/part_3/coverage_noimprove/ contiene la copertura di baseline della Parte 1 per il confronto.

3. Parte 4: Riproduzione della PoC di CVE-2020-27347

Questo script crea un'immagine Docker dedicata (da submission/part_4/environment/Dockerfile) e testa tmux 3.1b (vulnerabile) rispetto al commit corretto a868bac.

Risultati e Scoperte Chiave

(Spiegazioni dettagliate, figure e tabelle sono disponibili nel report.pdf completo)

Parte 1 (Baseline - input-fuzzer)

• Con corpus di seed predefinito: 14.00% di copertura delle righe (7281/51997 righe), 24.44% di copertura delle funzioni.
• Senza corpus di seed: 13.94% di copertura delle righe (7248/51997 righe), 24.31% di copertura delle funzioni.
• L'impatto del corpus di seed iniziale è stato minimo per l'input-fuzzer esistente.
• Porzioni significative di tmux, in particolare il parsing degli argomenti (arguments.c), il parsing/esecuzione dei comandi (cmd-parse.c, cmd-*.c) e la logica client/server (client.c, server.c), erano in gran parte non esercitate (ad es., arguments.c con ~5.8% di copertura delle righe).

Parte 3 (Miglioramenti del Fuzzer)

• argument-fuzzer (mirato a arguments.c): ha raggiunto il 66.62% di copertura delle righe per arguments.c, un aumento sostanziale rispetto alla baseline di ~5.8%.
• cmd-fuzzer (mirato al parsing ed esecuzione dei comandi): ha aumentato la copertura delle righe per cmd-parse.c al 42.58% (dal ~27%) e la copertura delle funzioni al 77.78%.
• Anche la copertura di arguments.c è salita al 45.54% tramite questo fuzzer.
• cmd.c ha raggiunto il 39.14% di copertura delle righe.
• Raggiunta una copertura nuova o significativamente migliorata in vari moduli cmd-*.c (ad es., cmd-bind-key.c, cmd-set-options.c fino al 50% di copertura delle funzioni) e nelle routine di gestione dei tasti (key-string.c fino al 30% di copertura delle righe, key-bindings.c fino al 6.05% di copertura delle righe).

Parte 4 (Analisi di CVE-2020-27347)

• Riprodotta con successo CVE-2020-27347 (stack buffer overflow nel parsing delle sequenze di escape SGR) su tmux 3.1b (commit 6a33a12) utilizzando il payload \033[::::::7::1:2:3::5:6:7:m.
• Confermato che il commit a868bac di tmux (che include la correzione e porta alla versione 3.1c) non era suscettibile al crash.
• La vulnerabilità, sfruttabile scrivendo una sequenza appositamente predisposta su una TTY di un pannello, porta a Denial of Service e ha il potenziale per Arbitrary Code Execution. È classificata come ad alta gravità (CVSS 7.8).

Sfide Affrontate

• Garantire un avvio corretto di tmux in un ambiente Docker scriptato, in particolare evitando errori "not a terminal", ha richiesto l'uso di sessioni staccate (detached) per la PoC della CVE.
• La gestione dello stato di git (garantire cloni completi e reset puliti prima dell'applicazione delle patch) nei diversi scenari di test è stata fondamentale per ottenere build riproducibili di versioni specifiche di tmux.
• Lo sviluppo di nuovi harness di fuzzing efficaci (argument-fuzzer, cmd-fuzzer) ha richiesto una buona comprensione della logica interna di parsing di argomenti e comandi di tmux per mirare a specifici percorsi di codice non esercitati.

Lavori Futuri

• Migliorare ulteriormente il cmd-fuzzer per coprire una gamma più ampia di moduli cmd-*.c, in particolare quelli che gestiscono interazioni di stato complesse come manipolazioni di finestre, layout o pannelli.
• Studiare strategie di fuzzing per il protocollo di comunicazione client-server di tmux, coinvolgendo potenzialmente un mocking più complesso dell'ambiente.
• Esplorare l'uso del fuzzing strutturato (structure-aware fuzzing) per il linguaggio dei comandi di tmux, possibilmente sfruttando le definizioni grammaticali di cmd-parse.y per generare sequenze di comandi sintatticamente più valide e complesse.

Link Utili

• Progetto tmux
• OSS-Fuzz
• CVE-2020-27347
• Report del Progetto (PDF) (Percorso relativo alla radice del progetto)