Fuzzing

En programación y desarrollo de software , el fuzzing o las pruebas de fuzzing son una técnica automatizada de prueba de software que consiste en proporcionar datos inválidos, inesperados o aleatorios como entrada a un programa informático . A continuación, se monitoriza el programa en busca de excepciones como fallos , errores en las aserciones de código integradas o posibles fugas de memoria . Normalmente, los fuzzers se utilizan para probar programas que aceptan entradas estructuradas. Esta estructura se especifica, por ejemplo, en un formato de archivo o protocolo , y distingue entre entradas válidas e inválidas. Un fuzzer eficaz genera entradas semiválidas que son "suficientemente válidas" en el sentido de que no son rechazadas directamente por el analizador sintáctico, pero que sí generan comportamientos inesperados en el programa y son "suficientemente inválidas" para exponer casos límite que no se han gestionado adecuadamente.

A efectos de seguridad, la entrada que cruza un límite de confianza suele ser la más útil. ^{[ 1 ]} Por ejemplo, es más importante realizar pruebas de fuzzing en el código que maneja un archivo subido por cualquier usuario que en el código que analiza un archivo de configuración al que solo tiene acceso un usuario privilegiado.

El término "fuzz" tiene su origen en un proyecto de clase de 1988 ^{[ 2 ]} en la asignatura de posgrado de Sistemas Operativos Avanzados (CS736), impartida por el profesor Barton Miller en la Universidad de Wisconsin , cuyos resultados se publicaron posteriormente en 1990. ^{[ 3 ] [ 4 ]} Para realizar pruebas de fuzzing a una utilidad de UNIX diseñada para generar automáticamente parámetros de entrada y de línea de comandos aleatorios para la utilidad. El proyecto fue diseñado para probar la fiabilidad de los programas de línea de comandos de UNIX ejecutando un gran número de entradas aleatorias en rápida sucesión hasta que fallaran. El equipo de Miller logró que fallara entre el 25 y el 33 por ciento de las utilidades que probaron. Luego depuraron cada uno de los fallos para determinar la causa y categorizaron cada fallo detectado. Para permitir que otros investigadores realizaran experimentos similares con otro software, el código fuente de las herramientas, los procedimientos de prueba y los datos de resultados brutos se pusieron a disposición del público. ^{[ 5 ]} Este fuzzing inicial ahora se denominaría fuzzing de caja negra, generacional, no estructurado (tonto o "clásico").

Según el profesor Barton Miller, «Durante el proceso de redacción de la descripción del proyecto, necesité darle un nombre a este tipo de prueba. Quería un nombre que evocara la sensación de datos aleatorios y no estructurados. Después de probar varias ideas, me decidí por el término fuzz». ^{[ 4 ]}

Una contribución clave de este trabajo inicial fue un oráculo sencillo (casi simplista). Un programa fallaba la prueba si se bloqueaba o se quedaba colgado con la entrada aleatoria; de lo contrario, se consideraba que la había superado. Si bien la construcción de oráculos de prueba puede ser compleja, el oráculo para estas primeras pruebas de fuzzing era sencillo y de aplicación universal.

En abril de 2012, Google anunció ClusterFuzz, una infraestructura de fuzzing basada en la nube para componentes críticos de seguridad del navegador web Chromium . ^{[ 6 ]} Los investigadores de seguridad pueden subir sus propios fuzzers y obtener recompensas por errores si ClusterFuzz encuentra un fallo con el fuzzer subido.

En septiembre de 2014, se reveló Shellshock ^{[ 7 ]} como una familia de fallos de seguridad en el intérprete de comandos Bash de UNIX , ampliamente utilizado ; la mayoría de las vulnerabilidades de Shellshock se encontraron utilizando el fuzzer AFL . ^{[ 8 ]} (Muchos servicios con acceso a Internet, como algunas implementaciones de servidores web, utilizan Bash para procesar ciertas solicitudes, lo que permite a un atacante hacer que versiones vulnerables de Bash ejecuten comandos arbitrarios . Esto puede permitir a un atacante obtener acceso no autorizado a un sistema informático. ^{[ 9 ]} )

En abril de 2015, Hanno Böck demostró cómo el fuzzer AFL podría haber encontrado la vulnerabilidad Heartbleed de 2014. ^{[ 10 ] [ 11 ]} (La vulnerabilidad Heartbleed se reveló en abril de 2014. Es una vulnerabilidad grave que permite a los atacantes descifrar comunicaciones que de otro modo estarían encriptadas . La vulnerabilidad se introdujo accidentalmente en OpenSSL , que implementa TLS y es utilizado por la mayoría de los servidores en internet. Shodan informó que 238.000 máquinas seguían siendo vulnerables en abril de 2016; ^{[ 12 ]} 200.000 en enero de 2017. ^{[ 13 ]} )

En agosto de 2016, la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA) celebró las finales del primer Cyber ​​Grand Challenge , una competición totalmente automatizada de captura de la bandera que duró 11 horas. ^{[ 14 ]} El objetivo era desarrollar sistemas de defensa automáticos que pudieran descubrir, explotar y corregir fallos de software en tiempo real . El fuzzing se utilizó como una estrategia ofensiva eficaz para descubrir fallos en el software de los oponentes. Demostró un enorme potencial en la automatización de la detección de vulnerabilidades. El ganador fue un sistema llamado "Mayhem" ^{[ 15 ]} desarrollado por el equipo ForAllSecure liderado por David Brumley .

En septiembre de 2016, Microsoft anunció Project Springfield, un servicio de pruebas de fuzzing basado en la nube para encontrar errores críticos de seguridad en el software. ^{[ 16 ]}

En diciembre de 2016, Google anunció OSS-Fuzz, que permite realizar pruebas de fuzzing continuas en varios proyectos de código abierto críticos para la seguridad. ^{[ 17 ]}

En Black Hat 2018, Christopher Domas demostró el uso de fuzzing para exponer la existencia de un núcleo RISC oculto en un procesador. ^{[ 18 ]} Este núcleo pudo eludir las comprobaciones de seguridad existentes para ejecutar comandos del Anillo 0 desde el Anillo 3.

En septiembre de 2020, Microsoft lanzó OneFuzz , una plataforma de fuzzing como servicio autohospedada que automatiza la detección de errores de software . ^{[ 19 ]} Es compatible con Windows y Linux. ^{[ 20 ]} Fue archivada tres años después, el 1 de noviembre de 2023. ^{[ 21 ]}

Las pruebas de programas con entradas aleatorias se remontan a la década de 1950, cuando los datos aún se almacenaban en tarjetas perforadas . ^{[ 22 ]} Los programadores utilizaban tarjetas perforadas sacadas de la basura o mazos de cartas con números aleatorios como entrada para los programas informáticos. Si una ejecución revelaba un comportamiento no deseado, se había detectado un error .

La ejecución de entradas aleatorias también se denomina prueba aleatoria , prueba de mono o depuración de Monte Carlo ^{[ 23 ]} (en analogía con los métodos de Monte Carlo ).

En 1981, Duran y Ntafos investigaron formalmente la efectividad de probar un programa con entradas aleatorias. ^{[ 24 ] [ 25 ]} Si bien las pruebas aleatorias se habían considerado ampliamente como el peor método para probar un programa, los autores pudieron demostrar que es una alternativa rentable a las técnicas de prueba más sistemáticas.

En 1983, Steve Capps de Apple desarrolló "The Monkey" ^{[ 26 ],} una herramienta que generaba entradas aleatorias para aplicaciones clásicas de Mac OS , como MacPaint ^{[ 27 ]} . El término figurativo "monkey" alude al teorema del mono infinito , que establece que un mono que pulsara teclas al azar en un teclado de máquina de escribir durante un tiempo infinito acabaría escribiendo todas las obras de Shakespeare. En el caso de las pruebas, el mono escribiría la secuencia específica de entradas que provocaría un fallo.

En 1991, se lanzó la herramienta crashme, cuyo objetivo era probar la robustez de los sistemas operativos Unix y similares mediante la ejecución aleatoria de llamadas al sistema con parámetros elegidos al azar. ^{[ 28 ]}

Un fuzzer se puede categorizar de varias maneras: ^{[ 29 ] [ 1 ]}

1. Un fuzzer puede basarse en la generación o en la mutación, dependiendo de si las entradas se generan desde cero o modificando entradas existentes.
2. Un fuzzer puede ser tonto (no estructurado) o inteligente (estructurado) dependiendo de si conoce o no la estructura de la entrada.
3. Un fuzzer puede ser de caja blanca, caja gris o caja negra, dependiendo de si conoce o no la estructura del programa.

Un fuzzer basado en mutación aprovecha un corpus existente de entradas semilla durante el fuzzing. Genera entradas modificando (o más bien mutando ) las semillas proporcionadas. ^{[ 30 ]} Por ejemplo, al realizar fuzzing en la biblioteca de imágenes libpng , el usuario proporcionaría un conjunto de archivos de imagen PNG válidos como semillas, mientras que un fuzzer basado en mutación modificaría estas semillas para producir variantes semiválidas de cada una. El corpus de archivos semilla puede contener miles de entradas potencialmente similares. La selección automatizada de semillas (o reducción del conjunto de pruebas) permite a los usuarios elegir las mejores semillas para maximizar el número total de errores encontrados durante una campaña de fuzzing. ^{[ 31 ]}

Un fuzzer basado en generaciones genera entradas desde cero. Por ejemplo, un fuzzer inteligente basado en generaciones ^{[ 32 ]} toma el modelo de entrada proporcionado por el usuario para generar nuevas entradas. A diferencia de los fuzzers basados ​​en mutaciones, un fuzzer basado en generaciones no depende de la existencia ni de la calidad de un corpus de entradas semilla.

Algunos fuzzers tienen la capacidad de hacer ambas cosas: generar entradas desde cero y generar entradas mediante la mutación de semillas existentes. ^{[ 33 ]}

Normalmente, los fuzzers se utilizan para generar entradas para programas que aceptan entradas estructuradas, como un archivo , una secuencia de eventos de teclado o ratón , o una secuencia de mensajes . Esta estructura distingue la entrada válida, que el programa acepta y procesa, de la entrada inválida, que el programa rechaza rápidamente. Lo que constituye una entrada válida puede especificarse explícitamente en un modelo de entrada. Ejemplos de modelos de entrada son las gramáticas formales , los formatos de archivo , los modelos de interfaz gráfica de usuario (GUI) y los protocolos de red . Incluso elementos que normalmente no se consideran entradas pueden ser sometidos a fuzzing, como el contenido de bases de datos , la memoria compartida , las variables de entorno o la intercalación precisa de hilos . Un fuzzer eficaz genera entradas semiválidas que son "lo suficientemente válidas" como para no ser rechazadas directamente por el analizador sintáctico y "lo suficientemente inválidas" como para poder poner a prueba casos límite y ejercitar comportamientos interesantes del programa.

Un fuzzer inteligente (basado en modelos, ^{[ 33 ]} basado en gramáticas, ^{[ 32 ] [ 34 ]} o basado en protocolos ^{[ 35 ]} ) aprovecha el modelo de entrada para generar una mayor proporción de entradas válidas. Por ejemplo, si la entrada se puede modelar como un árbol de sintaxis abstracta , entonces un fuzzer inteligente basado en mutaciones ^{[ 34 ]} emplearía transformaciones aleatorias para mover subárboles completos de un nodo a otro. Si la entrada se puede modelar mediante una gramática formal , un fuzzer inteligente basado en generación ^{[ 32 ]} instanciaría las reglas de producción para generar entradas que sean válidas con respecto a la gramática. Sin embargo, generalmente el modelo de entrada debe proporcionarse explícitamente, lo cual es difícil de hacer cuando el modelo es propietario, desconocido o muy complejo. Si se dispone de un gran corpus de entradas válidas e inválidas, una técnica de inducción gramatical , como el algoritmo L* de Angluin , podría generar un modelo de entrada. ^{[ 36 ] [ 37 ]}

Un fuzzer tonto ^{[ 38 ] [ 39 ]} no requiere el modelo de entrada y, por lo tanto, puede emplearse para probar una mayor variedad de programas. Por ejemplo, AFL es un fuzzer tonto basado en mutación que modifica un archivo semilla invirtiendo bits aleatorios , sustituyendo bytes aleatorios con valores "interesantes" y moviendo o eliminando bloques de datos. Sin embargo, un fuzzer tonto podría generar una menor proporción de entradas válidas y sobrecargar el código del analizador sintáctico en lugar de los componentes principales de un programa. La desventaja de los fuzzers tontos puede ilustrarse mediante la construcción de una suma de verificación válida para una comprobación de redundancia cíclica (CRC). Una CRC es un código de detección de errores que garantiza que la integridad de los datos contenidos en el archivo de entrada se preserve durante la transmisión . Se calcula una suma de verificación sobre los datos de entrada y se registra en el archivo. Cuando el programa procesa el archivo recibido y la suma de verificación registrada no coincide con la suma de verificación recalculada, el archivo se rechaza como inválido. Ahora bien, es improbable que un fuzzer que desconozca el CRC genere la suma de verificación correcta. Sin embargo, existen intentos de identificar y recalcular una posible suma de verificación en la entrada mutada, una vez que un fuzzer simple basado en mutaciones ha modificado los datos protegidos. ^{[ 40 ]}

Por lo general, se considera que un fuzzer es más efectivo si logra una mayor cobertura de código . La razón es que, si un fuzzer no prueba ciertos elementos estructurales del programa, tampoco podrá detectar errores ocultos en ellos. Algunos elementos del programa se consideran más críticos que otros. Por ejemplo, un operador de división podría provocar un error de división por cero , o una llamada al sistema podría bloquear el programa.

Un fuzzer de caja negra ^{[ 38 ] [ 34 ]} trata el programa como una caja negra y desconoce su estructura interna. Por ejemplo, una herramienta de prueba aleatoria que genera entradas al azar se considera un fuzzer de caja negra. Por lo tanto, un fuzzer de caja negra puede ejecutar cientos de entradas por segundo, se puede paralelizar fácilmente y puede escalar a programas de tamaño arbitrario. Sin embargo, los fuzzers de caja negra pueden solo rascar la superficie y exponer errores "superficiales". Por lo tanto, hay intentos de desarrollar fuzzers de caja negra que puedan aprender incrementalmente sobre la estructura interna (y el comportamiento) de un programa durante el fuzzing observando la salida del programa a partir de una entrada. Por ejemplo, LearnLib emplea aprendizaje activo para generar un autómata que representa el comportamiento de una aplicación web.

Un fuzzer de caja blanca ^{[ 39 ] [ 33 ]} aprovecha el análisis del programa para aumentar sistemáticamente la cobertura del código o para alcanzar ciertas ubicaciones críticas del programa. Por ejemplo, SAGE ^{[ 41 ]} aprovecha la ejecución simbólica para explorar sistemáticamente diferentes rutas en el programa (una técnica conocida como ejecución concólica ). Si la especificación del programa está disponible, un fuzzer de caja blanca podría aprovechar técnicas de pruebas basadas en modelos para generar entradas y verificar las salidas del programa con respecto a la especificación del programa. Un fuzzer de caja blanca puede ser muy eficaz para exponer errores que se ocultan profundamente en el programa. Sin embargo, el tiempo empleado para el análisis (del programa o su especificación) puede llegar a ser prohibitivo. Si el fuzzer de caja blanca tarda demasiado en generar una entrada, un fuzzer de caja negra será más eficiente. ^{[ 42 ]} Por lo tanto, existen intentos de combinar la eficiencia de los fuzzers de caja negra y la efectividad de los fuzzers de caja blanca. ^{[ 43 ]}

Un fuzzer de caja gris utiliza instrumentación en lugar de análisis de programas para obtener información sobre el programa. Por ejemplo, AFL y libFuzzer utilizan instrumentación ligera para rastrear las transiciones de bloques básicos realizadas por una entrada. Esto genera una sobrecarga de rendimiento razonable, pero informa al fuzzer sobre el aumento en la cobertura de código durante el fuzzing, lo que convierte a los fuzzers de caja gris en herramientas de detección de vulnerabilidades extremadamente eficientes. ^{[ 44 ]}

El fuzzing se utiliza principalmente como una técnica automatizada para exponer vulnerabilidades en programas críticos para la seguridad que podrían ser explotadas con intenciones maliciosas. ^{[ 6 ] [ 16 ] [ 17 ]} En términos más generales, el fuzzing se utiliza para demostrar la presencia de errores en lugar de su ausencia. Ejecutar una campaña de fuzzing durante varias semanas sin encontrar un error no prueba que el programa sea correcto. ^{[ 45 ]} Después de todo, el programa aún puede fallar para una entrada que aún no se ha ejecutado; ejecutar un programa para todas las entradas es prohibitivamente costoso. Si el objetivo es probar que un programa es correcto para todas las entradas, debe existir una especificación formal y deben utilizarse técnicas de métodos formales .

Para detectar errores, un fuzzer debe ser capaz de distinguir el comportamiento esperado (normal) del inesperado (con errores) del programa. Sin embargo, una máquina no siempre puede distinguir un error de una funcionalidad. En las pruebas de software automatizadas , esto también se conoce como el problema del oráculo de prueba . ^{[ 46 ] [ 47 ]}

Normalmente, un fuzzer distingue entre entradas que provocan fallos y entradas que no los provocan, en ausencia de especificaciones , y utiliza una medida simple y objetiva. Los fallos se pueden identificar fácilmente y podrían indicar vulnerabilidades potenciales (por ejemplo, denegación de servicio o ejecución de código arbitrario ). Sin embargo, la ausencia de un fallo no indica la ausencia de una vulnerabilidad. Por ejemplo, un programa escrito en C puede o no fallar cuando una entrada provoca un desbordamiento de búfer . En cambio, el comportamiento del programa es indefinido .

Para que un fuzzer sea más sensible a fallos distintos de los bloqueos, se pueden usar sanitizadores para inyectar aserciones que bloqueen el programa cuando se detecta un fallo. ^{[ 48 ] [ 49 ]} Hay diferentes sanitizadores para diferentes tipos de errores:

• para detectar errores relacionados con la memoria, como desbordamientos de búfer y uso después de su liberación (utilizando depuradores de memoria como AddressSanitizer ),
• para detectar condiciones de carrera y bloqueos mutuos (ThreadSanitizer),
• para detectar comportamiento indefinido (UndefinedBehaviorSanitizer),
• para detectar fugas de memoria (LeakSanitizer), o
• para comprobar la integridad del flujo de control (CFISanitizer).

El fuzzing también puede utilizarse para detectar errores "diferenciales" si se dispone de una implementación de referencia . Para las pruebas de regresión automatizadas , ^{[ 50 ]} las entradas generadas se ejecutan en dos versiones del mismo programa. Para las pruebas diferenciales automatizadas , ^{[ 51 ]} las entradas generadas se ejecutan en dos implementaciones del mismo programa (por ejemplo, lighttpd y httpd son implementaciones de un servidor web). Si las dos variantes producen una salida diferente para la misma entrada, entonces una de ellas podría tener un error y debería examinarse con mayor detenimiento.

El análisis estático de programas analiza un programa sin ejecutarlo realmente. Esto puede generar falsos positivos, donde la herramienta informa problemas con el programa que en realidad no existen. El fuzzing, en combinación con el análisis dinámico de programas, puede utilizarse para intentar generar una entrada que reproduzca el problema reportado. ^{[ 52 ]}

Los navegadores web modernos se someten a extensas pruebas de fuzzing. El código Chromium de Google Chrome es sometido continuamente a pruebas de fuzzing por el Equipo de Seguridad de Chrome con 15 000 núcleos. ^{[ 53 ]} Para Microsoft Edge [Legacy] e Internet Explorer , Microsoft realizó pruebas de fuzzing con 670 años-máquina durante el desarrollo del producto, generando más de 400 000 millones de manipulaciones del DOM a partir de 1 000 millones de archivos HTML. ^{[ 54 ] [ 53 ]}

Un fuzzer produce una gran cantidad de entradas en un tiempo relativamente corto. Por ejemplo, en 2016, el proyecto Google OSS-fuzz produjo alrededor de 4 billones de entradas por semana. ^{[ 17 ]} Por lo tanto, muchos fuzzers proporcionan un conjunto de herramientas que automatiza tareas manuales y tediosas que siguen a la generación automatizada de entradas que provocan fallos.

El triaje automatizado de errores se utiliza para agrupar un gran número de entradas que provocan fallos según su causa raíz y para priorizar cada error individual según su gravedad. Un fuzzer produce un gran número de entradas, y muchas de las que provocan fallos pueden exponer efectivamente el mismo error de software . Solo algunos de estos errores son críticos para la seguridad y deben parchearse con mayor prioridad. Por ejemplo, el Centro de Coordinación CERT proporciona las herramientas de triaje de Linux que agrupan las entradas que provocan fallos según el rastreo de pila producido y enumeran cada grupo según su probabilidad de ser explotable . ^{[ 55 ]} El Centro de Investigación de Seguridad de Microsoft (MSEC) desarrolló la herramienta "!exploitable" que primero crea un hash para una entrada que provoca un fallo para determinar su unicidad y luego asigna una calificación de explotabilidad: ^{[ 56 ]}

• Explotable
• Probablemente explotable
• Probablemente no sea explotable, o
• Desconocido.

Los errores previamente no reportados y clasificados podrían ser reportados automáticamente a un sistema de seguimiento de errores . Por ejemplo, OSS-Fuzz realiza campañas de fuzzing a gran escala y de larga duración para varios proyectos de software críticos para la seguridad, donde cada error distinto previamente no reportado se reporta directamente a un sistema de seguimiento de errores. ^{[ 17 ]} El sistema de seguimiento de errores de OSS-Fuzz informa automáticamente al responsable del software vulnerable y comprueba a intervalos regulares si el error se ha corregido en la revisión más reciente utilizando la entrada minimizada que induce el fallo cargada.

La minimización automática de la entrada (o reducción de casos de prueba) es una técnica de depuración automatizada para aislar la parte de la entrada que provoca el fallo y que realmente lo está causando. ^{[ 57 ] [ 58 ]} Si la entrada que provoca el fallo es grande y en su mayoría está mal formada, puede resultar difícil para un desarrollador comprender qué es exactamente lo que causa el error. Dada la entrada que provoca el fallo, una herramienta de minimización automatizada eliminaría tantos bytes de entrada como sea posible sin dejar de reproducir el error original. Por ejemplo, la depuración Delta es una técnica de minimización automática de la entrada que emplea un algoritmo de búsqueda binaria extendido para encontrar dicha entrada mínima. ^{[ 59 ]}

A continuación se presenta una lista de fuzzers descritos como "populares", "ampliamente utilizados" o similares en la literatura académica. ^{[ 60 ] [ 61 ]}

• American fuzzy lop (fuzzer)
• Pruebas de concólico
• Fallo
• Fallos
• Pruebas con monos
• Pruebas aleatorias
• Divulgación coordinada de vulnerabilidades
• Detección de errores en tiempo de ejecución
• Pruebas de seguridad
• Pruebas de humo (software)
• Ejecución simbólica
• Pruebas del sistema
• Automatización de pruebas

• Nappa, A.; Blázquez, E. (2023). Fuzzing Against the Machine: Automatiza la investigación de vulnerabilidades con dispositivos IoT emulados en Qemu . Packt Publishing, Limited. ISBN 9781804614976.Una guía completa sobre la investigación automatizada de vulnerabilidades con dispositivos IoT emulados.
• Zeller, Andrés; Gopinath, Rahul; Böhme, Marcel; Fraser, Gordon; Grita, cristiano (2019). El libro fuzzing . Sarrebruck: CISPA + Universidad del Sarre.Un libro de texto introductorio gratuito en línea sobre fuzzing.
• Ari Takanen, Jared D. DeMott, Charles Miller, Fuzzing para pruebas de seguridad de software y garantía de calidad , 2008, ISBN 978-1-59693-214-2
• Michael Sutton, Adam Greene y Pedram Amini. Fuzzing: Descubrimiento de vulnerabilidades mediante fuerza bruta , 2007, ISBN 0-321-44611-9.
• H. Pohl, Identificación rentable de vulnerabilidades de día cero con la ayuda de modelado de amenazas y fuzzing , 2011
• Fabien Duchene, Detección de vulnerabilidades web mediante fuzzing evolutivo asistido por inferencia de modelos, 2014, Tesis doctoral
• Bratus, Sergey; Darley, Trey; Locasto, Michael; Patterson, Meredith L.; Shapiro, Rebecca Bx; Shubina, Anna; "Bx" Shapiro, Rebecca; Shubina, Anna (2014). "Más allá de los errores plantados en "Confiar en la confianza": La frontera del procesamiento de entradas". IEEE Security & Privacy . 12 (1): 83– 87. Bibcode : 2014ISPri..12a..83M . doi : 10.1109/MSP.2014.1 .—Básicamente, esto pone de manifiesto por qué el fuzzing funciona tan bien: porque la entrada es el programa que controla al intérprete.

• El proyecto Fuzzing incluye tutoriales, una lista de proyectos de código abierto críticos para la seguridad y otros recursos.
• Pruebas de fuzzing de la Universidad de Wisconsin (el proyecto de fuzzing original). Fuente de artículos y software de fuzzing.
• Diseño de entradas que provocan fallos en el software , vídeo de la conferencia que incluye pruebas difusas.
• Creación de marcos de trabajo de fuzzing "conscientes del protocolo"