A pesar de que un proyecto puede haber sido sometido a un exhaustivo proceso de fuzzing durante años, algunos errores pueden persistir. El OSS-Fuzz, una de las iniciativas de seguridad más significativas en el ámbito del código abierto, ha ayudado a identificar miles de vulnerabilidades en software de código abierto desde su creación, en colaboración con la Fundación OpenSSF. Actualmente, OSS-Fuzz lleva a cabo el fuzzing de más de 1,300 proyectos de código abierto sin costo para los mantenedores. Sin embargo, este enfoque no es una solución mágica; incluso proyectos maduros que han estado en el programa durante años pueden contener serias vulnerabilidades que pasan desapercibidas.
Recientemente, se han auditado varios proyectos populares que están inscritos en OSS-Fuzz, y se han descubierto vulnerabilidades significativas que han sobrevivido durante años. Por ejemplo, GStreamer, el marco multimedia predeterminado para el entorno de escritorio GNOME, mostró 29 nuevas vulnerabilidades, muchas de las cuales eran de alto riesgo. A pesar de haber sido objeto de fuzzing durante siete años, sus estadísticas revelan que solo tiene dos generadores de fuzzing activos y una cobertura de código de aproximadamente 19%. En contraste, proyectos bien investigados como OpenSSL cuentan con 139 generadores de fuzzing y muchas más proporciones de cobertura de código.
Esta diferencia destaca que el OSS-Fuzz aún requiere supervisión humana para gestionar la cobertura de los proyectos y para crear nuevos fuzzers para el código no cubierto. Además, existe una percepción errónea entre los desarrolladores sobre la seguridad que brinda estar en OSS-Fuzz, lo que puede llevar a una falsa sensación de protección. Muchos no son expertos en seguridad y entienden el fuzzing como un simple requisito en su lista de verificación de seguridad.
Otro caso es el de Poppler, la biblioteca predeterminada para el análisis de PDFs en Ubuntu. Aunque cuenta con 16 generadores de fuzz y aproximadamente un 60% de cobertura de código, se descubrió una vulnerabilidad crítica que permitía la ejecución remota de código. Este caso subraya el hecho de que las dependencias externas también son críticas; si estas bibliotecas no están incluidas en el proceso de fuzzing, su código puede no ser evaluado, dejando caminos de ejecución sin probar.
Un tercer ejemplo es Exiv2, que permite leer y modificar los metadatos en imágenes. A pesar de estar en OSS-Fuzz durante más de tres años, nuevas vulnerabilidades han sido reportadas por otros investigadores. Esto ejemplifica un patrón común en el fuzzing de formatos de medios: se tiende a concentrar la atención en la decodificación, descuidando la codificación y dejando pasar vulnerabilidades que podrían haber permanecido ocultas durante años.
Estos casos reflejan claramente que el fuzzing no es infalible. Aunque puede ser eficaz para detectar un gran número de bugs, algunas vulnerabilidades pueden evadirlo. Factores como la cobertura de código, la atención a las dependencias externas y la necesidad de una revisión manual son esenciales para mejorar la eficacia del fuzzing. Los investigadores abogan por un enfoque más proactivo donde se combine el fuzzing con otras metodologías, como el análisis estático y la revisión manual, para asegurar que el software sea verdaderamente seguro ante amenazas emergentes.
vía: GitHub Security
