Fuzzing o fuzz testing es una técnica de prueba de software automatizada que implica proporcionar datos no válidos, inesperados o aleatorios como entradas a un programa de computadora . Luego, el programa se monitorea para detectar excepciones como fallas , afirmaciones de código incorporadas fallidas o posibles fugas de memoria . Normalmente, los fuzzers se utilizan para probar programas que toman entradas estructuradas. Esta estructura se especifica, por ejemplo, en un formato de archivo o protocoloy distingue la entrada válida de la inválida. Un fuzzer efectivo genera entradas semi-válidas que son "suficientemente válidas" en el sentido de que no son rechazadas directamente por el analizador, pero crean comportamientos inesperados más profundamente en el programa y son "lo suficientemente inválidos" para exponer casos de esquina que no se han tratado correctamente. con.
Por motivos de seguridad, la información que cruza un límite de confianza suele ser la más útil. [1] Por ejemplo, es más importante el código fuzz que maneja la carga de un archivo por cualquier usuario que el código que analiza un archivo de configuración que es accesible solo para un usuario privilegiado.
Historia
El término "fuzz" se origina en un proyecto de la clase de otoño de 1988 [2] en la clase de posgrado de Sistemas Operativos Avanzados (CS736), impartida por el Prof. Barton Miller en la Universidad de Wisconsin, cuyos resultados se publicaron posteriormente en 1990. [3] Para fuzz prueba una utilidad de UNIX destinada a generar automáticamente archivos aleatorios y parámetros de línea de comandos para la utilidad. El proyecto fue diseñado para probar la confiabilidad de los programas de línea de comandos de UNIX ejecutando una gran cantidad de entradas aleatorias en rápida sucesión hasta que fallaron. El equipo de Miller pudo bloquear entre el 25 y el 33 por ciento de los servicios públicos que probaron. Luego depuraron cada una de las fallas para determinar la causa y categorizaron cada falla detectada. Para permitir que otros investigadores lleven a cabo experimentos similares con otro software, el código fuente de las herramientas, los procedimientos de prueba y los datos de los resultados sin procesar se pusieron a disposición del público. [4] Este fuzzing temprano ahora se llamaría fuzzing de caja negra, generacional, no estructurado (tonto).
Este artículo de 1990 también notó la relación entre la confiabilidad y la seguridad: "En segundo lugar, uno de los errores que encontramos fue causado por la misma práctica de programación que proporcionó uno de los agujeros de seguridad al gusano de Internet (el error 'mete el dedo'). Hemos encontrado errores adicionales que podrían indicar brechas de seguridad en el futuro ". (Refiriéndose al gusano Morris de noviembre de 1988).
El proyecto fuzz original continuó haciendo contribuciones en 1995, 2000, 2006 y más recientemente en 2020:
- 1995: [5] El artículo "fuzz revisited" constaba de cuatro partes. (1) Reprodujo el estudio de línea de comandos original, incluida una variedad más amplia de sistemas UNIX y más utilidades. El estudio mostró que, en todo caso, la confiabilidad había empeorado. Este fue el primer estudio que incluyó utilidades GNU y Linux de código abierto que, curiosamente, eran significativamente más confiables que las de los sistemas UNIX comerciales. (2) Introdujo la prueba fuzz de aplicaciones GUI (basadas en ventanas) bajo X-Windows. Este estudio utilizó datos de entrada estructurados y no estructurados (secuencias válidas de eventos de mouse y teclado). Fueron capaces de bloquear el 25% de las aplicaciones X-Windows. Además, probaron el servidor X-Windows y demostraron que era resistente a los bloqueos. (3) Introdujo la prueba de fuzz de los servicios de red, nuevamente basada en la entrada de prueba estructurada. Ninguno de estos servicios se bloqueó. (4) Se introdujeron pruebas aleatorias de los valores de retorno de llamadas de la biblioteca del sistema, específicamente devolviendo cero aleatoriamente de la familia de funciones malloc. Casi la mitad de los programas estándar de UNIX no comprobaron correctamente dichos valores devueltos.
- 2000: [6] Se aplicó la prueba fuzz al sistema operativo Windows NT recientemente lanzado , probando aplicaciones que se ejecutaban bajo el sistema de ventanas Win32 . Pudieron bloquear el 21% de las aplicaciones y colgar un 24% adicional de las probadas. Una vez más, las aplicaciones se estaban probando con entradas estructuradas y no estructuradas (eventos de teclado y mouse válidos), lo que provocó fallas en casi la mitad de las aplicaciones que probaron. Identificaron las causas de las fallas y encontraron que eran similares a estudios anteriores.
- 2006: [7] Se aplicó la prueba fuzz a Mac OS X , tanto para la línea de comandos como para las aplicaciones basadas en ventanas. Probaron 135 programas de utilidad de línea de comandos, bloqueando el 7% de los probados. Además, probaron 30 aplicaciones que se ejecutaban bajo el sistema de ventanas MacOS Aqua , bloqueando el 73% de las probadas.
- 2020: [8] Más recientemente, aplicaron las clásicas pruebas generacionales, de caja negra, no estructuradas a los sistemas UNIX actuales, especialmente Linux, FreeBSD y MacOS, para ver si las técnicas originales seguían siendo relevantes y si los programas de utilidad actuales eran resistentes a este tipo. de prueba. Probaron aproximadamente 75 utilidades en cada plataforma, con tasas de falla del 12% en Linux, 16% en MacOS y 19% en FreeBSD. (Tenga en cuenta que estas tasas de fallas fueron peores que los resultados de la prueba anterior de los mismos sistemas). Cuando analizaron cada falla y las categorizaron, encontraron que las categorías clásicas de fallas, como errores de puntero y matriz y no verificar los códigos de retorno, todavía estaban ampliamente presentes en los nuevos resultados. Además, surgieron nuevas causas de fallas a partir del estado complejo del programa y los algoritmos que no se escalaron con el tamaño o la complejidad de la entrada. También probaron las utilidades de UNIX escritas más recientemente en Rust y encontraron que tenían una confiabilidad similar a las escritas en C, aunque (como era de esperar) era menos probable que tuvieran errores de memoria.
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 . [9] Los investigadores de seguridad pueden cargar sus propios fuzzers y recolectar recompensas por errores si ClusterFuzz encuentra una falla con el fuzzer cargado.
En septiembre de 2014, Shellshock [10] fue revelado como una familia de errores de seguridad en el shell UNIX Bash ampliamente utilizado ; la mayoría de las vulnerabilidades de Shellshock se encontraron utilizando el fuzzer AFL . [11] (Muchos servicios de Internet, como algunas implementaciones de servidores web, usan Bash para procesar ciertas solicitudes, lo que permite que un atacante haga que las versiones vulnerables de Bash ejecuten comandos arbitrarios . Esto puede permitir que un atacante obtenga acceso no autorizado a una computadora sistema. [12] )
En abril de 2015, Hanno Böck mostró cómo el fuzzer AFL podría haber encontrado la vulnerabilidad Heartbleed 2014. [13] [14] (La vulnerabilidad Heartbleed se reveló en abril de 2014. Es una vulnerabilidad grave que permite a los adversarios descifrar comunicaciones que de otro modo estarían cifradas . La vulnerabilidad se introdujo accidentalmente en OpenSSL, que implementa TLS y es utilizada por la mayoría de los servidores en internet. Shodan reportó 238.000 máquinas sigue siendo vulnerable en abril de 2016; [15] 200.000 en enero de 2017. [16] )
En agosto de 2016, la Agencia de Proyectos de Investigación Avanzada de Defensa (DARPA) celebró la final del primer Cyber Grand Challenge , una competencia de captura de la bandera totalmente automatizada que duró 11 horas. [17] El objetivo era desarrollar sistemas de defensa automáticos que pudieran descubrir, explotar y corregir fallas de software en tiempo real . Fuzzing se utilizó como una estrategia ofensiva eficaz para descubrir fallas en el software de los oponentes. Mostró un tremendo potencial en la automatización de la detección de vulnerabilidades. El ganador fue un sistema llamado "Mayhem" [18] desarrollado por el equipo ForAllSecure dirigido por David Brumley .
En septiembre de 2016, Microsoft anunció Project Springfield, un servicio de prueba de fuzz basado en la nube para encontrar errores críticos de seguridad en el software. [19]
En diciembre de 2016, Google anunció OSS-Fuzz, que permite el fuzzing continuo de varios proyectos de código abierto críticos para la seguridad. [20]
En Black Hat 2018, Christopher Domas demostró el uso de fuzzing para exponer la existencia de un núcleo RISC oculto en un procesador. [21] Este núcleo pudo eludir los controles de seguridad existentes para ejecutar comandos de Ring 0 desde Ring 3.
En septiembre de 2020, Microsoft lanzó OneFuzz , un auto-organizada plataforma de formación de pelusa-as-a-servicio que automatiza la detección de errores de software . [22] Es compatible con Windows y Linux. [23]
Pruebas aleatorias tempranas
Los programas de prueba con entradas aleatorias se remontan a la década de 1950, cuando los datos aún se almacenaban en tarjetas perforadas . [24] Los programadores usarían tarjetas perforadas que fueron sacadas de la basura o mazos de tarjetas de números aleatorios como entrada para programas de computadora. Si una ejecución reveló un comportamiento no deseado, se había detectado un error .
La ejecución de entradas aleatorias también se denomina prueba aleatoria o prueba de mono .
En 1981, Duran y Ntafos investigaron formalmente la efectividad de probar un programa con entradas aleatorias. [25] [26] Si bien las pruebas aleatorias se percibían ampliamente como el peor medio de 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", [27] una herramienta que generaría entradas aleatorias para aplicaciones clásicas de Mac OS , como MacPaint . [28] El "mono" figurativo se refiere al teorema del mono infinito que establece que un mono que pulsa teclas al azar en el teclado de una máquina de escribir durante un tiempo infinito acabará escribiendo la obra completa de Shakespeare. En el caso de las pruebas, el mono escribiría la secuencia particular de entradas que desencadenarían un bloqueo.
En 1991, se lanzó la herramienta crashme, cuyo objetivo era probar la solidez de los sistemas operativos Unix y similares a Unix mediante la ejecución aleatoria de llamadas a sistemas con parámetros elegidos al azar. [29]
Tipos
Un fuzzer se puede clasificar de varias formas: [30] [1]
- Un fuzzer puede estar basado en generaciones o mutaciones dependiendo de si las entradas se generan desde cero o modificando las entradas existentes.
- Un fuzzer puede ser tonto o inteligente dependiendo de si es consciente de la estructura de entrada.
- Un fuzzer puede ser de caja blanca, gris o negra, dependiendo de si conoce la estructura del programa.
Reutilización de semillas de insumos existentes
Un difusor basado en mutaciones aprovecha un corpus existente de entradas de semillas durante el fuzzing. Genera entradas modificando (o más bien mutando ) las semillas proporcionadas. [31] 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 mutaciones modificaría estas semillas para producir variantes semiválidas de cada semilla. El corpus de archivos semilla puede contener miles de entradas potencialmente similares. La selección de semillas automatizada (o la 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 fuzz. [32]
Un fuzzer basado en generaciones genera entradas desde cero. Por ejemplo, un fuzzer basado en generación inteligente [33] 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 o calidad de un corpus de entradas de semillas.
Algunos fuzzers tienen la capacidad de hacer ambas cosas, generar insumos desde cero y generar insumos por mutación de semillas existentes. [34]
Consciente de la estructura de entrada
Por lo general, los fuzzers se utilizan para generar entradas para programas que toman entradas estructuradas, como un archivo , una secuencia de eventos de teclado o mouse , o una secuencia de mensajes . Esta estructura distingue la entrada válida que es aceptada y procesada por el programa de la entrada no válida que es rápidamente rechazada por el programa. Lo que constituye una entrada válida puede especificarse explícitamente en un modelo de entrada. Ejemplos de modelos de entrada son gramáticas formales , formatos de archivo , modelos de GUI y protocolos de red . Incluso los elementos que normalmente no se consideran como entrada pueden confundirse, como el contenido de las bases de datos , la memoria compartida , las variables de entorno o el entrelazado preciso de subprocesos . Un fuzzer efectivo genera entradas semi-válidas que son "suficientemente válidas" para que no sean rechazadas directamente por el analizador y "suficientemente inválidas" para que puedan enfatizar casos de esquina y ejercitar comportamientos interesantes del programa.
Un fuzzer inteligente (basado en modelo, [34] basado en gramática, [33] [35] o basado en protocolo [36] ) 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 [35] emplearía transformaciones aleatorias para mover subárboles completos de un nodo a otro. Si la entrada puede modelarse mediante una gramática formal , un fuzzer inteligente basado en la generación [33] instanciaría las reglas de producción para generar entradas que sean válidas con respecto a la gramática. Sin embargo, en general, el modelo de entrada debe proporcionarse explícitamente, lo que 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. [37] [38]
Un difusor tonto [39] [40] no requiere el modelo de entrada y, por lo tanto, puede emplearse para difuminar una variedad más amplia de programas. Por ejemplo, AFL es un difusor tonto basado en mutaciones que modifica un archivo semilla volteando bits aleatorios , sustituyendo bytes aleatorios con valores "interesantes" y moviendo o borrando bloques de datos. Sin embargo, un difusor tonto podría generar una proporción menor de entradas válidas y estresar el código del analizador en lugar de los componentes principales de un programa. La desventaja de los fuzzers tontos se puede ilustrar mediante la construcción de una suma de verificación válida para una verificación de redundancia cíclica (CRC). Un 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 conserve durante la transmisión . Se calcula una suma de comprobación sobre los datos de entrada y se registra en el archivo. Cuando el programa procesa el archivo recibido y la suma de comprobación registrada no coincide con la suma de comprobación recalculada, el archivo se rechaza como inválido. Ahora bien, es poco probable que un fuzzer que desconozca el CRC genere la suma de comprobación correcta. Sin embargo, hay intentos de identificar y volver a calcular una suma de comprobación potencial en la entrada mutada, una vez que un fuzzer mutado basado en mutación ha modificado los datos protegidos. [41]
Consciente de la estructura del programa
Normalmente, un fuzzer se considera más eficaz si logra un mayor grado de cobertura de código . La razón es que, si un fuzzer no ejerce ciertos elementos estructurales en el programa, tampoco puede revelar los errores que se esconden en estos elementos. Algunos elementos del programa se consideran más críticos que otros. Por ejemplo, un operador de división puede causar un error de división por cero , o una llamada al sistema puede bloquear el programa.
Un fuzzer de caja negra [39] [35] trata el programa como una caja negra y desconoce la estructura interna del programa. 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 varios cientos de entradas por segundo, se puede paralelizar fácilmente y se puede escalar a programas de tamaño arbitrario. Sin embargo, los fuzzers de caja negra solo pueden rayar la superficie y exponer errores "superficiales". Por lo tanto, hay intentos de desarrollar fuzzers de caja negra que pueden aprender de manera incremental sobre la estructura interna (y el comportamiento) de un programa durante el fuzzing al observar la salida del programa dada una entrada. Por ejemplo, LearnLib emplea el aprendizaje activo para generar un autómata que representa el comportamiento de una aplicación web.
Un fuzzer de caja blanca [40] [34] aprovecha el análisis del programa para aumentar sistemáticamente la cobertura del código o para llegar a determinadas ubicaciones críticas del programa. Por ejemplo, SAGE [42] aprovecha la ejecución simbólica para explorar sistemáticamente diferentes caminos en el programa. Si la especificación del programa está disponible, un fuzzer de caja blanca podría aprovechar las técnicas de las pruebas basadas en modelos para generar entradas y comparar las salidas del programa con la especificación del programa. Un fuzzer de caja blanca puede ser muy eficaz para exponer errores que se esconden en las profundidades del programa. Sin embargo, el tiempo empleado para el análisis (del programa o su especificación) puede volverse prohibitivo. Si el fuzzer de caja blanca tarda demasiado en generar una entrada, un fuzzer de caja negra será más eficiente. [43] Por lo tanto, hay intentos de combinar la eficiencia de los fuzzers de caja negra y la efectividad de los fuzzers de caja blanca. [44]
Un fuzzer de caja gris aprovecha la instrumentación en lugar del análisis del programa para obtener información sobre el programa. Por ejemplo, AFL y libFuzzer utilizan instrumentación liviana para rastrear las transiciones de bloques básicas ejercidas por una entrada. Esto conduce a una sobrecarga de rendimiento razonable, pero informa al fuzzer sobre el aumento en la cobertura del código durante el fuzzing, lo que hace que los fuzzers de caja gris sean herramientas de detección de vulnerabilidades extremadamente eficientes. [45]
Usos
Fuzzing se usa principalmente como una técnica automatizada para exponer vulnerabilidades en programas críticos para la seguridad que podrían explotarse con intenciones maliciosas. [9] [19] [20] De manera más general, el fuzzing se usa 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. [46] 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 caro. Si el objetivo es probar que un programa es correcto para todas las entradas, debe existir una especificación formal y se deben utilizar técnicas de métodos formales .
Exponer errores
Para exponer errores, un fuzzer debe poder distinguir el comportamiento esperado (normal) del programa inesperado (con errores). Sin embargo, una máquina no siempre puede distinguir un error de una característica. En las pruebas de software automatizadas , esto también se denomina problema de prueba de Oracle . [47] [48]
Por lo general, un fuzzer distingue entre entradas bloqueadas y no bloqueadas en ausencia de especificaciones y para usar una medida simple y objetiva. Los bloqueos se pueden identificar fácilmente y pueden indicar vulnerabilidades potenciales (por ejemplo, denegación de servicio o ejecución de código arbitrario ). Sin embargo, la ausencia de un accidente no indica la ausencia de una vulnerabilidad. Por ejemplo, un programa escrito en C puede fallar o no cuando una entrada provoca un desbordamiento del búfer . Más bien, el comportamiento del programa no está definido .
Para hacer que un fuzzer sea más sensible a fallas que no sean bloqueos, se pueden usar desinfectantes para inyectar afirmaciones que bloquean el programa cuando se detecta una falla. [49] [50] Existen diferentes desinfectantes para diferentes tipos de insectos:
- para detectar errores relacionados con la memoria, como desbordamientos de búfer y uso después de la liberación (usando depuradores de memoria como AddressSanitizer ),
- para detectar condiciones de carrera y puntos muertos (ThreadSanitizer),
- para detectar un comportamiento indefinido (UndefinedBehaviorSanitizer),
- para detectar fugas de memoria (LeakSanitizer), o
- para comprobar la integridad del flujo de control (CFISanitizer).
Fuzzing también se puede utilizar para detectar errores "diferenciales" si hay una implementación de referencia disponible. Para las pruebas de regresión automatizadas , [51] las entradas generadas se ejecutan en dos versiones del mismo programa. Para las pruebas diferenciales automatizadas , [52] 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 puede tener errores y debe examinarse más de cerca.
Validación de informes de análisis estáticos
El análisis de programa estático analiza un programa sin ejecutarlo realmente. Esto puede dar lugar a falsos positivos en los que 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 se puede utilizar para tratar de generar una entrada que sea testigo del problema informado. [53]
Seguridad del navegador
Los navegadores web modernos experimentan una gran confusión. El equipo de seguridad de Chrome difumina continuamente el código Chromium de Google Chrome con 15.000 núcleos. [54] Para Microsoft Edge e Internet Explorer , Microsoft realizó pruebas difusas con 670 años-máquina durante el desarrollo del producto, generando más de 400 mil millones de manipulaciones DOM a partir de mil millones de archivos HTML. [55] [54]
Cadena de herramientas
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. [20] Por lo tanto, muchos fuzzers proporcionan una cadena de herramientas que automatiza tareas que de otro modo serían manuales y tediosas que siguen a la generación automatizada de entradas que inducen fallas.
Triaje de errores automatizado
La clasificación de errores automatizada se utiliza para agrupar una gran cantidad de entradas que inducen fallas por causa raíz y para priorizar cada error individual por gravedad. Un fuzzer produce una gran cantidad de entradas, y muchas de las que provocan fallas pueden exponer efectivamente el mismo error de software . Solo algunos de estos errores son críticos para la seguridad y deben corregirse con mayor prioridad. Por ejemplo, el Centro de Coordinación CERT proporciona las herramientas de clasificación de Linux que agrupan las entradas que fallan por el seguimiento de la pila producido y enumera cada grupo de acuerdo con su probabilidad de ser explotable . [56] El Centro de Investigación de Seguridad de Microsoft (MSEC) desarrolló la herramienta! Explotable que primero crea un hash para una entrada que falla para determinar su singularidad y luego asigna una calificación de explotabilidad: [57]
- Explotable
- Probablemente explotable
- Probablemente no explotable, o
- Desconocido.
Es posible que los errores evaluados previamente no informados se notifiquen automáticamente a un sistema de seguimiento de errores . Por ejemplo, OSS-Fuzz ejecuta campañas de fuzzing a gran escala y de larga duración para varios proyectos de software críticos para la seguridad en los que cada error distinto y no informado previamente se informa directamente a un rastreador de errores. [20] El rastreador de errores OSS-Fuzz informa automáticamente al responsable del mantenimiento del software vulnerable y verifica en intervalos regulares si el error se ha corregido en la revisión más reciente utilizando la entrada minimizada que induce a fallas.
Minimización de entrada automatizada
La minimización de entrada automatizada (o reducción de casos de prueba) es una técnica de depuración automatizada para aislar la parte de la entrada que induce fallas y que en realidad induce la falla. [58] [59] Si la entrada que induce a fallas es grande y en su mayoría está mal formada, puede ser difícil para un desarrollador entender qué es exactamente lo que está causando el error. Dada la entrada que induce a fallas, una herramienta de minimización automatizada eliminaría tantos bytes de entrada como fuera posible mientras aún reproduce el error original. Por ejemplo, la depuración delta es una técnica de minimización de entrada automatizada que emplea un algoritmo de búsqueda binaria extendido para encontrar una entrada mínima. [60]
Ver también
- Lop difuso americano (fuzzer)
- Prueba concólica
- Prueba de mono
- Pruebas aleatorias
- Divulgación responsable
- Detección de errores en tiempo de ejecución
- Pruebas de seguridad
- Prueba de humo (software)
- Ejecución simbólica
- Prueba del sistema
- Automatización de pruebas
Referencias
- ↑ a b John Neystadt (febrero de 2008). "Pruebas de penetración automatizadas con fuzzing de caja blanca" . Microsoft . Consultado el 14 de mayo de 2009 .
- ^ Barton P. Miller (septiembre de 1988). "Lista de proyectos de otoño de 1988 CS736" (PDF) . Departamento de Ciencias de la Computación, Universidad de Wisconsin-Madison . Consultado el 30 de diciembre de 2020 .
- ^ Barton P. Miller; Lars Fredriksen; Bryan So (diciembre de 1990). "Un estudio empírico de la confiabilidad de las utilidades de UNIX" (PDF) . Comunicaciones de la ACM .
- ^ "Fuzz Testing de confiabilidad de la aplicación" . Universidad de Wisconsin-Madison . Consultado el 30 de diciembre de 2020 .
- ^ Barton P. Miller; David Koski; Cjin P. Lee; Vivekananda Maganty; Ravbi Murthy; Ajitkumar Natarajan; Jeff Steidl (abril de 1995). "Fuzz revisited: un nuevo examen de la confiabilidad de las utilidades y servicios de UNIX" (PDF) . Informe técnico de ciencias de la computación # 1268, Universidad de Wisconsin-Madison .
- ^ Justin Forrester; Barton P. Miller (septiembre de 2000). "Un estudio empírico de la solidez de las aplicaciones de Windows NT mediante pruebas aleatorias" (PDF) . 4º Simposio de Sistemas Windows de USENIX .
- ^ Barton P. Miller; Gregory Cooksey; Fredrick Moore (julio de 2006). "Un estudio empírico de la solidez de las aplicaciones de MacOS mediante pruebas aleatorias" (PDF) . Primer Taller Internacional de Pruebas Aleatorias .
- ^ Barton P. Miller; Mengxiao Zhang; Elisa Heymann (2021). "La relevancia de las pruebas de fuzz clásicas: ¿Hemos resuelto este?" (PDF) . Transacciones IEEE sobre ingeniería de software .
- ^ a b "Anuncio de ClusterFuzz" . Consultado el 9 de marzo de 2017 .
- ^ Perlroth, Nicole (25 de septiembre de 2014). "Los expertos en seguridad esperan que el error de software 'Shellshock' en Bash sea significativo" . The New York Times . Consultado el 25 de septiembre de 2014 .
- ^ Zalewski, Michał (1 de octubre de 2014). "Bash bug: los otros dos RCE, o cómo eliminamos la corrección original (CVE-2014-6277 y '78)" . Blog de lcamtuf . Consultado el 13 de marzo de 2017 .
- ^ Seltzer, Larry (29 de septiembre de 2014). "Shellshock hace que Heartbleed parezca insignificante" . ZDNet . Consultado el 29 de septiembre de 2014 .
- ^ Böck, Hanno. "Fuzzing: Wie man Heartbleed hätte finden können (en alemán)" . Golem.de (en alemán) . Consultado el 13 de marzo de 2017 .
- ^ Böck, Hanno. "Cómo se pudo haber encontrado Heartbleed (en inglés)" . Blog de Hanno . Consultado el 13 de marzo de 2017 .
- ^ "Motor de búsqueda de Internet de las cosas - dispositivos aún vulnerables a Heartbleed" . shodan.io . Consultado el 13 de marzo de 2017 .
- ^ "Informe Heartbleed (2017-01)" . shodan.io . Consultado el 10 de julio de 2017 .
- ^ Walker, Michael. "DARPA Cyber Grand Challenge" . darpa.mil . Consultado el 12 de marzo de 2017 .
- ^ "Mayhem ocupa el primer lugar en CGC" . Consultado el 12 de marzo de 2017 .
- ^ a b "Anuncio del proyecto Springfield" . 2016-09-26 . Consultado el 8 de marzo de 2017 .
- ^ a b c d "Anunciando OSS-Fuzz" . Consultado el 8 de marzo de 2017 .
- ^ Christopher Domas (agosto de 2018). "MODO DIOS DESBLOQUEADO - Puertas traseras de hardware en CPU x86" . Consultado el 3 de septiembre de 2018 .
- ^ "Microsoft: Windows 10 está reforzado con estas herramientas de seguridad difusas, ahora son de código abierto" . ZDNet . 15 de septiembre de 2020.
- ^ "Marco de prueba de fuzzing de fuentes abiertas de Microsoft" . InfoWorld . 17 de septiembre de 2020.
- ^ Gerald M. Weinberg (5 de febrero de 2017). "Fuzz Testing e Historia de Fuzz" . Consultado el 6 de febrero de 2017 .
- ^ Joe W. Duran; Simeon C. Ntafos (9 de marzo de 1981). Un informe sobre pruebas aleatorias . Icse '81. Actas de la Conferencia Internacional ACM SIGSOFT sobre Ingeniería de Software (ICSE'81). págs. 179-183. ISBN 9780897911467.
- ^ Joe W. Duran; Simeon C. Ntafos (1 de julio de 1984). "Una evaluación de pruebas aleatorias". Transacciones IEEE sobre ingeniería de software . Transacciones IEEE sobre ingeniería de software (TSE) (4): 438–444. doi : 10.1109 / TSE.1984.5010257 . S2CID 17208399 .
- ^ Andy Hertzfeld (2004). Revolución en el valle: ¿La increíblemente genial historia de cómo se hizo la Mac? . Prensa O'Reily. ISBN 978-0596007195.
- ^ "Historias de Macintosh: Monkey Lives" . Folklore.org. 1999-02-22 . Consultado el 28 de mayo de 2010 .
- ^ "crashme" . CodePlex . Consultado el 21 de mayo de 2021 .
- ^ Michael Sutton; Adam Greene; Pedram Amini (2007). Fuzzing: Descubrimiento de vulnerabilidades de fuerza bruta . Addison-Wesley. ISBN 978-0-321-44611-4.
- ^ Offutt, Jeff; Xu, Wuzhi (2004). "Generación de casos de prueba para servicios web mediante perturbación de datos" . Taller de Testing, Análisis y Verificación de Servicios Web .
- ^ Rebert, Alexandre; Cha, Sang Kil; Avgerinos, Thanassis; Foote, Jonathan; Warren, David; Grieco, Gustavo; Brumley, David (2014). "Optimización de la selección de semillas para pelusa" (PDF) . Actas de la 23ª Conferencia USENIX sobre Simposio de Seguridad : 861–875.
- ^ a b c Patrice Godefroid; Adam Kiezun; Michael Y. Levin. "Fuzzing Whitebox basado en gramática" (PDF) . Investigación de Microsoft.
- ^ a b c Van-Thuan Pham; Marcel Böhme; Abhik Roychoudhury (7 de septiembre de 2016). "Fuzzing whitebox basado en modelos para programas binarios". Actas de la 31a Conferencia Internacional IEEE / ACM sobre Ingeniería de Software Automatizada - ASE 2016 . Actas de Ingeniería de Software Automatizada (ASE'16). págs. 543–553. doi : 10.1145 / 2970276.2970316 . ISBN 9781450338455. S2CID 5809364 .
- ^ a b c "Melocotón Fuzzer" . Consultado el 8 de marzo de 2017 .
- ^ Greg Banks; Marco Cova; Viktoria Felmetsger; Kevin Almeroth; Richard Kemmerer; Giovanni Vigna. SNOOZE: Hacia un fuzZEr de protocolo de red con estado . Actas de la Conferencia de Seguridad de la Información (ISC'06).
- ^ Osbert Bastani; Rahul Sharma; Alex Aiken; Percy Liang (junio de 2017). Sintetizar gramáticas de entrada de programas . Actas de la Conferencia ACM SIGPLAN sobre diseño e implementación de lenguajes de programación (PLDI 2017). arXiv : 1608.01723 . Código bibliográfico : 2016arXiv160801723B .
- ^ "VDA Labs - sistema de fuzzing evolutivo" . Archivado desde el original el 5 de noviembre de 2015 . Consultado el 14 de mayo de 2009 .
- ^ a b Ari Takanen; Jared D. Demott; Charles Miller (31 de enero de 2018). Fuzzing para pruebas de seguridad de software y control de calidad, segunda edición . Casa Artech. pag. 15. ISBN 978-1-63081-519-6. documento completo disponible ( archivado el 19 de septiembre de 2018)
- ^ a b Vijay Ganesh; Tim Leek; Martin Rinard (16 de mayo de 2009). "Fuzzing de caja blanca dirigido basado en la corrupción" . Actas de la Conferencia Internacional ACM SIGSOFT sobre Ingeniería de Software (ICSE'09).
- ^ Wang, T .; Wei, T .; Gu, G .; Zou, W. (mayo de 2010). TaintScope: una herramienta de fuzzing dirigida por sumas de comprobación para la detección automática de vulnerabilidades de software . Simposio IEEE 2010 sobre seguridad y privacidad . págs. 497–512. CiteSeerX 10.1.1.169.7866 . doi : 10.1109 / SP.2010.37 . ISBN 978-1-4244-6894-2. S2CID 11898088 .
- ^ Patrice Godefroid; Michael Y. Levin; David Molnar (8 de febrero de 2008). "Prueba automatizada de fuzz de Whitebox" (PDF) . Actas del Simposio de redes y sistemas distribuidos (NDSS'08).
- ^ Marcel Böhme; Soumya Paul (5 de octubre de 2015). "Un análisis probabilístico de la eficiencia de las pruebas de software automatizadas". Transacciones IEEE sobre ingeniería de software . 42 (4): 345–360. doi : 10.1109 / TSE.2015.2487274 . S2CID 15927031 .
- ^ Nick Stephens; John Grosen; Christopher Salls; Andrew Dutcher; Ruoyu Wang; Jacopo Corbetta; Yan Shoshitaishvili; Christopher Kruegel; Giovanni Vigna (24 de febrero de 2016). Perforador: Aumento. Difusión a través de la ejecución simbólica selectiva (PDF) . Actas del Simposio de redes y sistemas distribuidos (NDSS'16).
- ^ Marcel Böhme; Van-Thuan Pham; Abhik Roychoudhury (28 de octubre de 2016). "Greybox Fuzzing basado en cobertura como cadena de Markov". Greybox Fuzzing basado en cobertura como una cadena de Markov . Actas de la Conferencia ACM sobre seguridad informática y de comunicaciones (CCS'16). págs. 1032–1043. doi : 10.1145 / 2976749.2978428 . ISBN 9781450341394. S2CID 3344888 .
- ^ Hamlet, Richard G .; Taylor, Ross (diciembre de 1990). "Las pruebas de partición no inspiran confianza". Transacciones IEEE sobre ingeniería de software . 16 (12): 1402-1411. doi : 10.1109 / 32.62448 .
- ^ Weyuker, Elaine J. (1 de noviembre de 1982). "Sobre la prueba de programas no probables" . The Computer Journal . 25 (4): 465–470. doi : 10.1093 / comjnl / 25.4.465 .
- ^ Barr, Earl T .; Harman, Mark; McMinn, Phil; Shahbaz, Muzammil; Yoo, Shin (1 de mayo de 2015). "El problema de Oracle en las pruebas de software: una encuesta" (PDF) . Transacciones IEEE sobre ingeniería de software . 41 (5): 507–525. doi : 10.1109 / TSE.2014.2372785 . S2CID 7165993 .
- ^ "Documentación del compilador de Clang" . clang.llvm.org . Consultado el 13 de marzo de 2017 .
- ^ "Opciones de desinfectante GNU GCC" . gcc.gnu.org . Consultado el 13 de marzo de 2017 .
- ^ Orso, Alessandro; Xie, Tao (2008). BERT: Prueba de regresión conductual . Actas del Taller internacional de análisis dinámico de 2008 (WODA 2008) . ACM. págs. 36–42. doi : 10.1145 / 1401827.1401835 . ISBN 9781605580548. S2CID 7506576 .
- ^ McKeeman, William M. (1998). "Pruebas diferenciales para software" (PDF) . Revista Técnica Digital . 10 (1): 100–107.
- ^ Babić, Domagoj; Martignoni, Lorenzo; McCamant, Stephen; Canción, amanecer (2011). Generación de pruebas automatizadas dinámicas dirigidas estáticamente . Actas del Simposio internacional de 2011 sobre pruebas y análisis de software . ACM. págs. 12-22. doi : 10.1145 / 2001420.2001423 . ISBN 9781450305624. S2CID 17344927 .
- ^ a b Sesterhenn, Eric; Wever, Berend-Jan; Orrù, Michele; Vervier, Markus (19 de septiembre de 2017). "Libro blanco de seguridad del navegador" (PDF) . X41D SEC GmbH.
- ^ "Mejoras de seguridad para Microsoft Edge (Microsoft Edge para profesionales de TI)" . Microsoft . 15 de octubre de 2017 . Consultado el 31 de agosto de 2018 .
- ^ "Herramientas de triaje CERT" . División CERT del Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie Mellon (CMU) . Consultado el 14 de marzo de 2017 .
- ^ "Microsoft! Explorable Crash Analyzer" . CodePlex . Consultado el 14 de marzo de 2017 .
- ^ "Reducción de casos de prueba" . 2011-07-18.
- ^ "Técnicas de reducción de casos de prueba de IBM" . 2011-07-18. Archivado desde el original el 10 de enero de 2016 . Consultado el 18 de julio de 2011 .
- ^ Zeller, Andreas; Hildebrandt, Ralf (febrero de 2002). "Simplificación y aislamiento de entradas inductoras de fallas" . Transacciones IEEE sobre ingeniería de software . 28 (2): 183–200. CiteSeerX 10.1.1.180.3357 . doi : 10.1109 / 32.988498 . ISSN 0098-5589 . Consultado el 14 de marzo de 2017 .
Otras lecturas
- Ari Takanen, Jared D. DeMott, Charles Miller, Fuzzing para pruebas de seguridad de software y control de calidad , 2008, ISBN 978-1-59693-214-2
- Michael Sutton, Adam Greene y Pedram Amini. Fuzzing: Brute Force Vulnerability Discovery , 2007, ISBN 0-321-44611-9 .
- H. Pohl, Identificación rentable de vulnerabilidades de día cero con la ayuda del modelado y difuminado de amenazas , 2011
- Fabien Duchene, Detección de vulnerabilidades web a través de la inferencia evolutiva asistida por modelos, 2014, Tesis doctoral
- Bratus, S., Darley, T., Locasto, M., Patterson, ML, Shapiro, RB, Shubina, A., Beyond Planted Bugs in "Trusted Trust": The Input-Processing Frontier , IEEE Security & Privacy Vol 12, Número 1, (enero-febrero de 2014), págs. 83–87 —Básicamente destaca por qué el fuzzing funciona tan bien: porque la entrada es el programa controlador del intérprete.
enlaces externos
- Fuzzing Project incluye tutoriales, una lista de proyectos de código abierto críticos para la seguridad y otros recursos.
- Fuzz Testing de la Universidad de Wisconsin (el proyecto fuzz original) Fuente de artículos y software fuzz.
- Diseño de entradas que hacen que el software falle , video de conferencia que incluye pruebas difusas
- Enlace al grupo de programación segura de la universidad de Oulu (Finlandia)
- Creación de marcos difusos 'conscientes del protocolo'