¿Sobreviven los bugs a la furia del fuzzing continuo? Descubre por qué la supervisión humana sigue siendo clave

El fuzzing se ha convertido en una herramienta indispensable en el mundo de la seguridad informática. Iniciativas como OSS-Fuzz han demostrado su valía al descubrir miles de bugs en software de código abierto. Pero, ¿es el fuzzing la panacea? Un análisis reciente del GitHub Security Lab revela que incluso los proyectos sometidos a fuzzing continuo durante años pueden albergar vulnerabilidades críticas sin detectar. ¡Veamos por qué!

¿Qué es el Fuzzing?

Para los que no estén familiarizados, el fuzzing (o *fuzz testing*) es una técnica automatizada de prueba de software que consiste en alimentar un programa con datos de entrada aleatorios o mutados y monitorizarlo en busca de excepciones o fallos. Es como darle martillazos al software para ver dónde se rompe.

Si quieres profundizar en el tema, GitHub ofrece un curso de Fuzzing 101 (en inglés).

El caso de GStreamer: Cobertura insuficiente

GStreamer, el framework multimedia predeterminado para el entorno de escritorio GNOME, fue analizado y se encontraron 29 nuevas vulnerabilidades a pesar de haber sido sometido a fuzzing continuo durante siete años. ¿La razón? Una cobertura de código relativamente baja, con solo dos fuzzers activos y alrededor del 19% de cobertura. En comparación, OpenSSL tiene 139 fuzzers y bzip2 reporta un 93.03% de cobertura.

Esto nos lleva a la primera conclusión clave: OSS-Fuzz requiere supervisión humana activa para monitorizar la cobertura del proyecto y escribir nuevos fuzzers para el código no cubierto. La automatización es genial, pero aún necesitamos ojos humanos que guíen el proceso.

Además, muchos desarrolladores, al no ser expertos en seguridad, ven el fuzzing como una casilla más que marcar en su lista de tareas. Una vez que su proyecto está “siendo fuzzeado”, asumen que está “protegido por Google” y se olvidan del tema. ¡Incluso si el proyecto falla durante la fase de compilación y ni siquiera está siendo fuzzeado!

Poppler y las dependencias olvidadas

Poppler, la biblioteca de análisis de PDF predeterminada en Ubuntu, cuenta con 16 fuzzers y una cobertura de código de alrededor del 60%, números decentes. Sin embargo, recientemente se descubrió una vulnerabilidad RCE (Ejecución Remota de Código) de un solo clic en Evince (el visor de documentos que usa Poppler). Para explotarla, la víctima solo necesita abrir un archivo malicioso.

¿Por qué OSS-Fuzz no detectó esta vulnerabilidad? La respuesta está en las dependencias externas. Poppler depende de bibliotecas como freetype, cairo y libpng, que no estaban instrumentadas por libFuzzer. Pero lo más grave es que algunas dependencias predeterminadas de Evince, como DjVuLibre, ni siquiera están incluidas en la compilación de OSS-Fuzz. ¡Millones de sistemas estaban usando una dependencia “sin fuzzear” por defecto!

Esto demuestra que la seguridad de un software está limitada por la seguridad de la dependencia más débil en su grafo de dependencias.

Exiv2: Vulnerabilidades en el lado oscuro de la codificación

Exiv2, una biblioteca C++ para leer y escribir metadatos en imágenes, ha estado en OSS-Fuzz durante más de tres años y ha revelado múltiples vulnerabilidades (CVE-2024-39695, CVE-2024-24826, y CVE-2023-44398). A pesar de ello, otros investigadores han reportado nuevas vulnerabilidades (CVE-2025-26623 y CVE-2025-54080).

En este caso, el problema reside en que la mayoría de los investigadores se centran en la parte de decodificación de los formatos multimedia, que es la superficie de ataque más obvia. La parte de codificación, en cambio, recibe mucha menos atención. Esto permite que las vulnerabilidades en la lógica de codificación permanezcan ocultas durante años.

Aunque una vulnerabilidad en la codificación pueda parecer menos peligrosa, estas bibliotecas se utilizan en muchos flujos de trabajo en segundo plano (generación de miniaturas, conversión de archivos, procesamiento en la nube, etc.), donde una vulnerabilidad de codificación puede tener un impacto crítico.

El Flujo de Trabajo de Fuzzing en 5 Pasos

Para asegurar una calidad mínima en el fuzzing, es crucial seguir una serie de criterios. Aquí te presento un flujo de trabajo de cinco pasos que ha dado buenos resultados:

1. Preparación del código: Optimizar el código objetivo para el fuzzing (eliminar checksums, reducir la aleatoriedad, etc.).
2. Mejora de la cobertura del código: Aumentar al máximo la cobertura, utilizando fuzzing iterativo y técnicas avanzadas como fault injection y snapshot fuzzing. Se recomienda una cobertura superior al 90%.
3. Mejora de la cobertura sensible al contexto: Rastrear no solo qué aristas del código se ejecutan, sino también el orden en que se ejecutan, para evitar falsos positivos.
4. Mejora de la cobertura de valores: Guiar el fuzzer por rangos de valores de variables, no solo por rutas de control-flujo.
5. Triaje: Analizar y clasificar los resultados del fuzzing para identificar las vulnerabilidades reales.

Los Bugs más escurridizos

Incluso con las mejores herramientas y técnicas, algunos bugs son especialmente difíciles de detectar:

• Bugs que requieren entradas muy grandes: La mayoría de los fuzzers limitan el tamaño máximo de entrada, lo que dificulta la detección de vulnerabilidades que solo se manifiestan con entradas de megabytes o gigabytes.
• Bugs que requieren “tiempo extra” para activarse: Vulnerabilidades que no se pueden activar dentro del límite de tiempo por ejecución utilizado por los fuzzers (generalmente 1-10 milisegundos). Un ejemplo es un desbordamiento de contador de referencias que tarda 12 horas en manifestarse.

Actualmente, los fuzzers convencionales no son capaces de detectar este tipo de vulnerabilidades. Para encontrarlas, es necesario recurrir a análisis estático, pruebas concolicas (simbólicas + concretas) o la vieja confiable: la revisión manual del código.

Conclusión

El fuzzing es una herramienta poderosa, pero no es una solución mágica que te protegerá de todo. El fuzzing continuo puede identificar vulnerabilidades, pero también puede fallar en la detección de algunos vectores de ataque. Sin un trabajo guiado por humanos, clases enteras de bugs han sobrevivido años de fuzzing continuo en proyectos populares y cruciales. El flujo de trabajo de fuzzing en cinco pasos propuesto busca ir más allá de la simple cobertura de código, abarcando también la cobertura sensible al contexto y la cobertura de valores.

Así que ya lo sabes, ¡no te confíes! El fuzzing es un aliado valioso, pero la seguridad informática requiere un enfoque holístico y una buena dosis de experiencia humana.

Fuente: GitHub Blog