Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
tmux-fuzzing — Fuzzing mejorado para tmux usando OSS-Fuzz. Incluye harness personalizados `cmd-fuzzer` y `argument-fuzzer` para una mejor cobertura de código y un PoC para `CVE-2020-27347` | Kitploit
Herramientas/GitHubGitHub/lucadibello/tmux-fuzzing
Análisis de VulnerabilidadesAnálisis de CódigoFuzzingAnálisis de BinariosAprendizaje y EducaciónLabs y Práctica
GitHublucadibello/tmux-fuzzing

tmux-fuzzing

Fuzzing mejorado para tmux usando OSS-Fuzz. Incluye harness personalizados `cmd-fuzzer` y `argument-fuzzer` para una mejor cobertura de código y un PoC para `CVE-2020-27347`

Ver Repositorio
1hace 1 añoAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

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 y varios módulos .

Estructura del Repositorio

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

root@kitploit:~
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.

root@kitploit:~
# Desde el directorio raíz del proyecto:
./submission/part_1/run.w_corpus.sh  # Ejecutar input-fuzzer con corpus de semillas predeterminado
./submission/part_1/run.wo_corpus.sh # Ejecutar input-fuzzer sin corpus de semillas

run.w_corpus.sh utiliza el comportamiento predeterminado de compilación de tmux con respecto a las semillas. run.wo_corpus.sh aplica submission/part_1/remove_seed_corpus.patch (a través de su oss-fuzz.diff local que invocaría este parche o integraría sus cambios) a oss-fuzz/projects/tmux/build.sh para asegurar que no se utilice un corpus de semillas inicial. Los informes de cobertura se exportan a submission/part_1/report/w_corpus/ y submission/part_1/report/wo_corpus/ respectivamente.

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

  • Mejora 1 (argument-fuzzer): Apunta a arguments.c.

    root@kitploit:~
    # Desde el directorio raíz del proyecto:
    ./submission/part_3/improve1/run.improve1.sh
    
  • Mejora 2 (cmd-fuzzer): Apunta a cmd-parse.c y la ejecución de comandos.

    root@kitploit:~
    # Desde el directorio raíz del proyecto:
    ./submission/part_3/improve2/run.improve2.sh
    

Cada script run.improveX.sh aplica su oss-fuzz.diff local y establece PROJECT_PATCH_FILE en su project.diff local (que agrega el nuevo código de fuzzer a tmux y actualiza Makefile.am). Los informes de cobertura se exportan a los respectivos directorios submission/part_3/improveX/coverage_improveX/. El directorio submission/part_3/coverage_noimprove/ contiene la cobertura base de la Parte 1 para comparación.

3. Parte 4: Reproducción de PoC de CVE-2020-27347

root@kitploit:~
# Desde el directorio raíz del proyecto:
./submission/part_4/run.poc.sh

Este script construye una imagen Docker dedicada (a partir de submission/part_4/environment/Dockerfile) y prueba tmux 3.1b (vulnerable) contra el commit parcheado a868bac.

Hallazgos Clave y Resultados

(Se pueden encontrar explicaciones detalladas, figuras y tablas en el report.pdf completo)

Parte 1 (Línea Base - input-fuzzer)

  • Con corpus de semillas predeterminado: 14.00% de cobertura de líneas (7281/51997 líneas), 24.44% de cobertura de funciones.
  • Sin corpus de semillas: 13.94% de cobertura de líneas (7248/51997 líneas), 24.31% de cobertura de funciones.
  • El impacto del corpus de semillas inicial fue menor para el input-fuzzer existente.
  • Porciones significativas de tmux, notablemente el análisis de argumentos (arguments.c), análisis/ejecución de comandos (cmd-parse.c, cmd-*.c), y la lógica de cliente/servidor (client.c, server.c), estaban en gran medida sin ejercitar (por ejemplo, arguments.c con ~5.8% de cobertura de líneas).

Parte 3 (Mejoras del Fuzzer)

  • argument-fuzzer (apuntando a arguments.c): Alcanzó un 66.62% de cobertura de líneas para arguments.c, un aumento sustancial desde la línea base de ~5.8%.
  • cmd-fuzzer (apuntando a análisis y ejecución de comandos): Incrementó la cobertura de líneas para cmd-parse.c al 42.58% (desde ~27%) y la cobertura de funciones al 77.78%.
  • La cobertura de arguments.c también aumentó al 45.54% a través de este fuzzer.
  • cmd.c alcanzó un 39.14% de cobertura de líneas.
  • Se logró una cobertura nueva o significativamente mejorada en varios módulos cmd-*.c (por ejemplo, cmd-bind-key.c, cmd-set-options.c al 50% de cobertura de funciones) y rutinas de manejo de teclas (key-string.c al 30% de cobertura de líneas, key-bindings.c al 6.05% de cobertura de líneas).

Parte 4 (Análisis de CVE-2020-27347)

  • Se reprodujo exitosamente CVE-2020-27347 (desbordamiento de búfer en pila en el análisis de secuencias de escape SGR) en tmux 3.1b (commit 6a33a12) usando el payload \033[::::::7::1:2:3::5:6:7:m.
  • Se confirmó que el commit a868bac de tmux (que incluye la corrección y lleva a la versión 3.1c) no era susceptible al fallo.
  • La vulnerabilidad, explotable escribiendo una secuencia manipulada en un TTY de panel, lleva a Denegación de Servicio y tiene potencial para Ejecución de Código Arbitrario. Está clasificada como alta severidad (CVSS 7.8).

Desafíos Encontrados

  • Asegurar el inicio correcto de tmux en un entorno Docker con scripts, particularmente evitando errores de "no es una terminal", requirió el uso de sesiones separadas para la PoC de CVE.
  • Gestionar el estado de git (asegurar clones completos, restablecimientos limpios antes de aplicar parches) a través de diferentes escenarios de prueba fue crítico para compilaciones reproducibles de versiones específicas de tmux.
  • Desarrollar nuevos arneses de fuzzing efectivos (argument-fuzzer, cmd-fuzzer) requirió una buena comprensión de la lógica interna de procesamiento de argumentos y comandos de tmux para apuntar a rutas de código específicas no ejercitadas.

Trabajo Futuro

  • Mejorar aún más el cmd-fuzzer para cubrir una gama más amplia de módulos cmd-*.c, especialmente aquellos que manejan interacciones de estado complejas como manipulaciones de ventanas, diseño o paneles.
  • Investigar estrategias de fuzzing para el protocolo de comunicación cliente-servidor de tmux, potencialmente involucrando simulación de entorno más compleja.
  • Explorar el uso de fuzzing consciente de la estructura para el lenguaje de comandos de tmux, posiblemente aprovechando definiciones gramaticales de cmd-parse.y para generar secuencias de comandos más sintácticamente válidas y complejas.

Enlaces Útiles

  • tmux Project
  • OSS-Fuzz
  • CVE-2020-27347
  • Project Report PDF
Descargar herramienta
cmd-parse.c
cmd-*.c
  • Evaluar la efectividad de estos nuevos arneses midiendo la cobertura de código alcanzada y comparándola con la línea base.
  • 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.