Laboratorio de Fuzzing: Mejorando el Fuzzing para tmux

Seguridad de Software @ EPFL, Primavera 2025

Resumen

En este laboratorio, mejoramos los esfuerzos de fuzzing para el multiplexor de terminal tmux dentro de la infraestructura OSS-Fuzz de Google. Primero establecimos una línea base evaluando la cobertura de código del arnés existente input-fuzzer, tanto con su corpus de semillas proporcionado como sin él, observando una cobertura inicial comparable. A continuación, identificamos dos regiones de código significativas en tmux que estaban poco ejercitadas por el fuzzer base. Para abordar estas brechas de cobertura, desarrollamos y evaluamos dos nuevos arneses de fuzzing dirigidos, cmd-fuzzer y argument-fuzzer, demostrando su capacidad para mejorar la cobertura en estas áreas previamente poco probadas. Como estas mejoras de fuzzing no descubrieron nuevas vulnerabilidades críticas dentro del período del proyecto, nuestro análisis de fallos se centró en una vulnerabilidad histórica conocida. Desarrollamos una prueba de concepto (PoC) para CVE-2020-27347 (un desbordamiento de búfer basado en la pila), analizamos su causa raíz, discutimos la corrección implementada y evaluamos sus implicaciones de seguridad.

Resumen del Proyecto y Objetivos

Este proyecto tuvo como objetivo aplicar y mejorar técnicas de fuzzing en el multiplexor de terminal de código abierto tmux, utilizando el marco OSS-Fuzz. El proyecto abarcó varias etapas clave:

1. Evaluación de Línea Base (Parte 1):

   • Entender y evaluar el arnés existente input-fuzzer para tmux.
   • Comparar su rendimiento de cobertura de código al ejecutarse con su corpus de semillas predeterminado frente a un corpus vacío.

2. Análisis de Brechas de Cobertura (Parte 2):

   • Analizar los informes de cobertura de la Parte 1 para identificar regiones de código significativas en tmux no ejercitadas adecuadamente por el input-fuzzer.
   • Centrarse en el análisis de argumentos (arguments.c) y la lógica de análisis/ejecución de comandos (cmd-parse.c, módulos cmd-*.c) como áreas clave para mejora.

3. Mejora del Fuzzer (Parte 3):

   • Desarrollar dos nuevos arneses de fuzzing dirigidos:
     • argument-fuzzer: Diseñado específicamente para probar la lógica de análisis de argumentos de línea de comandos en arguments.c.
     • cmd-fuzzer: Diseñado para probar las rutas de análisis y ejecución de comandos, apuntando a cmd-parse.c y varios módulos cmd-*.c.
   • Evaluar la efectividad de estos nuevos arneses midiendo la cobertura de código alcanzada y comparándola con la línea base.

4. Análisis de Fallos (Parte 4):

   • Dado que no se descubrieron nuevas vulnerabilidades críticas mediante los fuzzers mejorados dentro del período del proyecto, se seleccionó una vulnerabilidad preexistente conocida en tmux (CVE-2020-27347) para un análisis en profundidad.
   • Esto implicó desarrollar una Prueba de Concepto (PoC) para reproducir el fallo, analizar su causa raíz, entender la corrección aplicada y evaluar sus implicaciones de seguridad.

Estructura del Repositorio

La presentación final está organizada de la siguiente manera (dentro del directorio submission/):

submission/
├── README.md                   # Este archivo
├── part_1/                     # Archivos para la Parte 1: Evaluación de Línea Base
│   ├── oss-fuzz.diff           # Diff para eliminar el corpus de semillas para input-fuzzer
│   ├── project.diff            # (Probablemente vacío o menor para la Parte 1)
│   ├── remove_seed_corpus.patch # El archivo de parche real utilizado
│   ├── report/                 # Informes de cobertura HTML para input-fuzzer
│   │   ├── w_corpus/
│   │   └── wo_corpus/
│   ├── run.w_corpus.sh         # Script para ejecutar input-fuzzer con corpus
│   └── run.wo_corpus.sh        # Script para ejecutar input-fuzzer sin corpus
├── part_3/                     # Archivos para la Parte 3: Mejoras del Fuzzer
│   ├── coverage_noimprove/     # Cobertura base (por ejemplo, de input-fuzzer sin corpus)
│   │   └── ...
│   ├── improve1/               # Mejora 1: argument-fuzzer
│   │   ├── coverage_improve1/  # Informe de cobertura para argument-fuzzer
│   │   ├── oss-fuzz.diff       # Cambios de configuración de OSS-Fuzz para argument-fuzzer
│   │   ├── project.diff        # Cambios de Tmux para argument-fuzzer (por ejemplo, nuevo .cc, Makefile.am)
│   │   └── run.improve1.sh     # Script para ejecutar argument-fuzzer
│   └── improve2/               # Mejora 2: cmd-fuzzer
│       ├── coverage_improve2/  # Informe de cobertura para cmd-fuzzer
│       ├── oss-fuzz.diff       # Cambios de configuración de OSS-Fuzz para cmd-fuzzer
│       ├── project.diff        # Cambios de Tmux para cmd-fuzzer
│       └── run.improve2.sh     # Script para ejecutar cmd-fuzzer
├── part_4/                     # Archivos para la Parte 4: Análisis de Fallos (CVE-2020-27347)
│   ├── environment/            # Entorno Docker para PoC
│   │   ├── Dockerfile
│   │   ├── run_tmux_cve_test.sh # Lógica central de prueba PoC
│   │   ├── test_fixed.sh
│   │   └── test_vulnerable.sh
│   └── run.poc.sh              # Script para construir la imagen Docker y ejecutar pruebas PoC
└── report.pdf                  # El informe completo del proyecto

(Nota: El directorio scripts/ que contiene _run_fuzz_core.sh es un ayudante y sería parte de la raíz si este README está en la raíz real del proyecto junto con submission/)

Configuración y Uso

Todas las campañas de fuzzing y la reproducción de la PoC de CVE están diseñadas para ejecutarse dentro de entornos Docker orquestados por scripts de shell.

Configuración y Uso

Requisitos previos:

• Docker instalado y ejecutándose en un sistema similar a Unix.
• Shell bash y cliente git.
• Claves SSH configuradas para [email protected] si los scripts necesitan clonar oss-fuzz (intentan clonar si no se encuentra oss-fuzz/ en la raíz del proyecto). Alternativamente, puede clonar previamente https://github.com/google/oss-fuzz.git en la raíz del proyecto.

Arquitectura General de Scripts: El proyecto utiliza un script centralizado, scripts/_run_fuzz_core.sh (no incluido en el directorio submission/ pero parte de la estructura general del proyecto que este README asume). Los scripts ejecutores individuales ubicados en submission/part_1/, submission/part_3/improve1/, submission/part_3/improve2/ y submission/part_4/ son responsables de:

1. Configurar el entorno de prueba específico aplicando parches oss-fuzz.diff específicos de la ejecución a una copia limpia del repositorio oss-fuzz (se espera que esté en ../../oss-fuzz en relación con la mayoría de los scripts ejecutores).
2. Exportar variables de configuración (como PROJECT, HARNESS, LABEL, rutas a parches específicos del proyecto y directorios de salida).
3. Invocar el script _run_fuzz_core.sh, que luego se encarga de:
   • Aplicar un parche opcional a nivel de proyecto (por ejemplo, para agregar nuevas fuentes de fuzzer a tmux).
   • Construir la imagen Docker de OSS-Fuzz (si está marcada).
   • Construir el/los fuzzer(s) especificado(s) con el sanitizador elegido.
   • Ejecutar el fuzzer durante la duración configurada (típicamente 4 horas).
   • Generar y exportar corpus e informes de cobertura HTML a las ubicaciones designadas dentro de la estructura de directorios submission/.

Ejecución de los Scripts: Generalmente se recomienda ejecutar los scripts ejecutores desde el directorio raíz del proyecto para asegurar la resolución correcta de rutas relativas para oss-fuzz/ y los directorios de salida.

1. Parte 1: Evaluación de Línea Base (input-fuzzer) Estos scripts evalúan el input-fuzzer existente para tmux.