A pesar de someter un proyecto a un exhaustivo proceso de verificación durante años, algunos errores pueden persistir. El OSS-Fuzz, una de las iniciativas más significativas en el ámbito de la seguridad del código abierto, ha identificado miles de vulnerabilidades gracias a su colaboración con la Fundación OpenSSF. A día de hoy, OSS-Fuzz testa más de 1,300 proyectos de código abierto de forma gratuita para sus mantenedores. No obstante, este método no es infalible; proyectos experimentados dentro del programa pueden contener serias vulnerabilidades que pasan desapercibidas.
Recientemente se auditaron varios proyectos populares inscritos en OSS-Fuzz y se encontraron vulnerabilidades significativas que habían pasado inadvertidas por años. Un caso destacado es GStreamer, el marco multimedia para GNOME, que mostró 29 nuevas vulnerabilidades, muchas de ellas de alto riesgo. A pesar de realizar fuzzing durante siete años, las estadísticas muestran que solo tiene dos generadores de fuzzing activos y una cobertura de código del 19%. Por otro lado, proyectos bien investigados como OpenSSL poseen 139 generadores y una cobertura mucho mayor.
Esta diferencia subraya que OSS-Fuzz todavía necesita la supervisión humana para gestionar la cobertura de código y crear nuevos fuzzers. Existe una falsa percepción entre los desarrolladores sobre la seguridad al estar en OSS-Fuzz, lo que puede inducir a un erróneo sentido de protección. Muchos no son expertos en seguridad y tratan el fuzzing como un simple requisito en su lista de verificación.
Poppler es otro ejemplo, siendo la biblioteca predeterminada para el análisis de PDFs en Ubuntu. Cuenta con 16 generadores y una cobertura del 60%, pero se descubrió una vulnerabilidad crítica que permitía la ejecución remota de código. Esto resalta la importancia de incluir dependencias externas en el proceso de fuzzing para no dejar caminos de ejecución sin probar.
Un tercer caso es Exiv2, herramienta para manejar metadatos en imágenes, que pese a su tiempo en OSS-Fuzz, ha tenido reportes de nuevas vulnerabilidades. Esto refleja un patrón común en el fuzzing de formatos de medios, donde se centra más en la decodificación que en la codificación, permitiendo que ciertas vulnerabilidades queden ocultas.
Estos ejemplos evidencian que el fuzzing no es infalible. Aunque es eficaz para detectar numerosos bugs, algunas vulnerabilidades pueden eludirlo. Factores como la cobertura de código, la atención a las dependencias y la revisión manual son esenciales para mejorar su eficacia. Los investigadores sugieren combinar el fuzzing con otras metodologías, como el análisis estático y la revisión manual, para garantizar que el software sea seguro ante nuevas amenazas.
