TL DR Aumentamos el bono del Programa Chrome Fuzzer de $ 500 a $ 1,000 como parte de nuestro reciente actualización de montos de recompensa.
Programa Chrome Fuzzer es parte del Programa de recompensa de vulnerabilidad de Google Chrome que permite a los investigadores de seguridad ejecutar sus fuzzers a escala en el ClusterFuzz infraestructura. Hace que la notificación de errores sea completamente automática, y los autores del fuzzer obtienen las mismas recompensas que si informaran los errores manualmente, además de un bono adicional ($ 1,000 a partir de ahora) además de cada nueva vulnerabilidad.
Ejecutamos fuzzers de forma indefinida, y algunos de los fuzzers que contribuyeron hace años todavía encuentran problemas de seguridad al cambiar el código de Chrome. Esto es beneficioso para ambas partes, ya que los investigadores de seguridad no tienen que perder tiempo analizando los bloqueos, y los desarrolladores de Chrome reciben informes de errores de alta calidad automáticamente.
Para obtener más información sobre el Programa Chrome Fuzzer, hablemos con Ned Williamson, que ha participado desde 2017 y ahora trabaja en el equipo de Seguridad de Google.
Q: Hola Ned! Parece que recibió más de $ 50,000 al participar en el Programa de recompensa de vulnerabilidad de Google Chrome con su quic_stream_manufacturing facility_fuzzer.
UNA: Sí, es verdad. Escribí un fuzzer para QUIC que me ayudó a encontrar e informar dos vulnerabilidades críticas, cada una con un valor de $ 10,000. Como sabía que mi fuzzer funcionaba bien, lo envié al programa Chrome Fuzzer. Luego, en los próximos meses, recibí esa recompensa tres veces más (más un bono), ya que el fuzzer detectó varias regresiones de seguridad en ClusterFuzz poco después de que ocurrieran.
Q: ¿Te has enfocado intencionalmente en las áreas que producen mayor gravedad problemas y mayores recompensas?
UNA: Sí. Si bien las vulnerabilidades en el código que son más críticas para la seguridad del usuario producen grandes cantidades de recompensas, en realidad comencé mirando errores de menor gravedad y comencé a buscar de manera gradual errores más graves hasta que pude encontrar errores críticos. Puedes ver esta progresión mirando el errores que informé manualmente como investigador externo.
Q: ¿Sugeriría comenzar buscando errores no críticos?
UNA: Yo diría que sí. El código crítico para la seguridad generalmente está mejor diseñado y auditado más a fondo, por lo que puede ser desalentador comenzar desde allí. Encontrar errores de seguridad menos críticos y recompensas ganadoras es una buena manera de generar confianza y mantenerse motivado.
Q: ¿Puedes compartir un algoritmo sobre cómo encontrar errores de seguridad en Chrome?
UNA: Mirar los informes de errores anteriores y existentes, incluso para los bloqueos que no son de seguridad, es una excelente manera de saber qué código es crítico para la seguridad y potencialmente defectuoso. A partir de ahí, si parece que algún código está expuesto a las entradas de los usuarios, configuraría una campaña fuzzing contra ese componente. Después de adquirir experiencia, no necesitará confiar en los informes existentes para encontrar una nueva superficie de ataque, lo que a su vez lo ayuda a encontrar lugares que no han sido considerados por investigadores anteriores. Este fue el caso de mi fuzzer QUIC.
Q: ¿Cómo aprendiste a escribir fuzzers?
UNA: No tenía ningún conocimiento especial sobre fuzzing antes de comenzar a buscar vulnerabilidades en Chrome. Seguí el documentación en el repositorio y todavía sigo el mismo proceso hoy.
Q: Tu fuzzer no es muy uncomplicated en comparación con muchos otros fuzzers. ¿Cómo llegaste a esa implementación?
UNA: La thought clave en el fuzzer QUIC fue darse cuenta de que las partes del código que manejaban los mensajes de texto sin formato después del descifrado eran propensas a la corrupción de la memoria. Por lo normal, el fuzzing no funciona bien con las entradas cifradas (es bastante difícil generar «al azar» un paquete que se pueda descifrar con éxito), por lo que amplié el código de prueba QUIC para permitir la prueba con el cifrado desactivado.
Q: ¿Hay otros buenos ejemplos de objetivos fuzz que empleen una lógica very similar?
UNA: Otro ejemplo es pdf_formcalc_context_fuzzer que envuelve la entrada fuzzing con un archivo PDF válido codificado, por lo tanto, enfoca fuzzing solo en la parte del script XFA. Como investigador, solo necesita elegir exactamente lo que desea difuminar y luego comprender cómo ejecutar ese código correctamente. Mirar las pruebas unitarias suele ser la forma más fácil de comprenderlo.
Enlaces útiles:
¡Feliz fuzzing y caza de insectos!
