Fundamentos de las pruebas fuzz: entradas guiadas por cobertura, corpus y triaje de fallos

Qué es

El fuzzing alimenta un programa con entradas generadas para encontrar fallos, bloqueos y aserciones incumplidas. Los fuzzers modernos están guiados por cobertura: la documentación de Go describe un motor que muta entradas, conserva como adiciones «interesantes» al corpus las que alcanzan código nuevo, y reporta las entradas que fallan tras minimizarlas. Un objetivo de fuzz (fuzz target) es una función pequeña que toma bytes o argumentos tipados y llama al código bajo prueba. La documentación de libFuzzer indica que, idealmente, el corpus debe sembrarse con una colección variada de entradas válidas e inválidas, y que el fuzzer funciona sin semillas pero de forma menos eficiente. OSS-Fuzz ejecuta fuzzers de forma continua para proyectos de código abierto con los motores libFuzzer, AFL++, Honggfuzz y Centipede combinados con sanitizers.

Por qué importa

Los analizadores sintácticos, decodificadores, manejadores de protocolo y todo lo demás que toca bytes no confiables tienen casos límite que nadie enumera: campos de longitud que desbordan, estructuras que anidan más profundo que la pila, codificaciones que cambian a mitad de flujo. Un fuzzer los explora de forma mecánica, y con sanitizers detecta errores de memoria que de otro modo pasarían inadvertidos. En lenguajes con seguridad de memoria, la ganancia son pánicos, bucles infinitos, agotamiento de recursos e invariantes rotas.

Cómo aplicarlo

• Elegir objetivos donde la entrada no sea confiable y el código sea rápido y determinista; la documentación de Go pide objetivos que no dependan de estado global porque se ejecutan en workers paralelos.
• Escribir el objetivo como una comprobación de propiedad, no solo «no falla»: ida y vuelta (decode(encode(x)) == x), comparación con una implementación de referencia, o verificación de invariantes tras la llamada.
• Sembrar el corpus con muestras reales y versionarlo; versionar también cada entrada minimizada que provocó un fallo como prueba de regresión (Go escribe las entradas que fallan en testdata/fuzz/ y las ejecuta con el go test habitual).
• Dar a la integración continua un presupuesto corto (un límite de tiempo o de iteraciones) y ejecutar sesiones largas de forma periódica o mediante un servicio como OSS-Fuzz; minimizar el corpus periódicamente (-merge=1 en libFuzzer) para que se mantenga pequeño sin perder cobertura.
• Construir los objetivos en C y C++ con sanitizers de direcciones y de comportamiento indefinido.

Trampas

Un objetivo que lee archivos o la red, o que es lento, deja sin recursos al motor. El fuzzing encuentra fallos, no respuestas incorrectas, salvo que el objetivo verifique algo. Los objetivos no deterministas producen reportes que nadie puede reproducir. La documentación de Go señala un tiempo de espera de 1 segundo por ejecución, por lo que una ruta lenta pero legítima se reporta como bloqueo. Un fuzzer nunca demuestra la ausencia de fallos; reduce la probabilidad de los tipos que puede provocar.