Vulnerabilidad en GnuPG calificada de “obvia”

El descubridor califica el problema de “obvio”, por lo que no se explica que lleve ahí desde hace casi 8 años.

El fallo está en la función make_printable_string del fichero openfile.c. Si un atacante crea un mensaje especialmente manipulado y la víctima lo abre en modo interactivo (circunstancia que limita su peligrosidad), se provocará un desbordamiento de memoria intermedia y es posible que permita la ejecución de código arbitrario en el sistema.

El fallo se da tanto en la versión estable 1.4.x como en la de desarrollo 2.x. El descubridor ha creado un parche, para quien quiera recompilar la herramienta. Por ahora, no existe nueva versión ejecutable que solucione el problema.

El propio descubridor confiesa que es posible que el fallo pueda ser aprovechado para ejecutar código, lo que convierte el problema en una amenaza a tener en cuenta. Otro de los comentarios que llama la atención en la alerta, es que el investigador habla de un fallo “bastante obvio” puesto que:

“La función make_printable_string debe reemplazar caracteres potencialmente peligrosos de una entrada por línea de comandos y devolver memoria reservada para una cadena. Puesto que esta cadena puede ser más larga que la original y el búfer para la entrada ha reservado sólo el tamaño de la cadena original… oops”.

Realmente sencillo. Y el fallo parece todavía más escandaloso cuando esta función ha estado ahí, en el código abierto desde julio de 1999. Casi ocho años. Este incidente recuerda (a menor escala) al que recientemente sufrió Microsoft con la función SetAbortProc. En ella se descubrió un fallo en enero de 2006 que estaba presente en el código de Windows desde 1990. Esto dio origen a la devastadora vulnerabilidad Windows MetaFile (WMF).

Y es que, código abierto o cerrado, ya lo dijo Alan Cox: “Lo que aparece en los medios de comunicación como que el código abierto es seguro y más fiable y que tiene menos fallos son afirmaciones muy peligrosas […] La alta calidad sólo se aplica a algunos proyectos, los que tienen buenos autores y buenas revisiones de código”. En resumen, la calidad no está tanto en el tipo de código, ni en el “código comparado con”… como en el código en sí, mejorado a través de buenas revisiones.