Aún se desconoce el propósito de reportar vulnerabilidades que ya fueron solucionadas hace años

Daniel Stenberg, autor de curl, advirtió a los usuarios, mediante una publicación de blog, sobre un informe por parte de la organización MITRE, de una vulnerabilidad crítica falsa.

El informe detalla sobre una vulnerabilidad a la cual se le asigno el CVE -ID «CVE-2020-19909 «y un nivel de gravedad de 9,8 sobre 10, que es típico de vulnerabilidades explotadas de forma remota que conducen a la ejecución de código con privilegios elevados.

En el informe de vulnerabilidad se hace referencia a un error en el código de análisis de la opción de línea de comandos «–retry-delay», que se solucionó en 2019 y provocó un desbordamiento de enteros. Dado que el error sólo se manifiesta cuando se pasa explícitamente un valor incorrecto al ejecutar la utilidad desde la línea de comando y conduce a una interpretación incorrecta del retraso antes de reenviar los datos, el error no se ha clasificado como una vulnerabilidad por los desarrolladores.

Esta es una historia que consta de varios pequeños bloques de construcción y ocurrieron dispersos en el tiempo y en diferentes lugares. Es una historia que muestra con claridad cómo nuestro sistema actual con ID CVE y mucha potencia otorgada a NVD es un sistema completamente roto.

Daniel Stenberg, menciona que el problema surge tres años después, cuando alguien envió un informe de vulnerabilidad a MITRE y asignó al problema un nivel de gravedad crítico.

Por lo cual en su publicación, realiza una crítica a MITRE, ya que dice que como es posible que esta organización «podría aceptar el nivel de gravedad indicado», ya que incluso si fuera una vulnerabilidad explotable, los problemas de denegación de servicio generalmente se ubican en otra categoría.

En el proyecto curl trabajamos duro y ferozmente en seguridad y siempre trabajamos con investigadores de seguridad que informan problemas. Presentamos nuestros propios CVE, los documentamos y nos aseguramos de contarle al mundo sobre ellos. Enumeramos más de 140 de ellos con todos los detalles imaginables sobre ellos proporcionados. Nuestro objetivo es proporcionar documentación de nivel oro para todo y eso incluye nuestras vulnerabilidades de seguridad pasadas.

Que alguien más haya enviado de repente un CVE para curl es una sorpresa. Esto no nos lo han dicho y realmente nos hubiera gustado. Ahora hay un nuevo CVE que informa un problema de rizo y no tenemos detalles que decir al respecto en el sitio web. No es bueno.

Es de destacar que los desarrolladores de curl recurrieron a MITRE con una solicitud para cancelar el informe CVE, pero los representantes de MITRE se limitaron a darse de baja, se negaron a eliminar el CVE y solo lo marcaron como controvertido («DISPUTED»).

Adicional a ello, se menciona que los «informes controvertidos» se envían de forma anónima a través del servicio de informes de vulnerabilidades de «NVD» y como tal hasta el momento el motivo de la publicación de este tipo de «vulnerabilidades falsas» no está claro.

Muchos de los que comentaron en la publicación del autor de Curl, parecen llegar a un punto en concreto, ya que mencionan que es probablemente alguien decidió demostrar la falta de una auditoría adecuada al recibir informes sobre vulnerabilidades, la posibilidad de utilizar CVE como mecanismo para desacreditar proyectos o llamar la atención sobre la solución de problemas potencialmente peligrosos en el código sin analizar su impacto en la seguridad.

Y es que incluso Jonathan White, del equipo de KeePassXC, bajo su nickname «droidmonkey», realizo un comentario en el cual hace referencia a que el equipo de KeePassXC también ha pasado por un asunto similar, lo cual refuerza la idea de que lo más probable es que alguien haya preparado informes basados ​​​​en el estudio de errores corregidos que potencialmente podrían conducir a vulnerabilidades, pero que los desarrolladores de los proyectos principales reconocieron que no afectan la seguridad (por ejemplo, podría haber un desbordamiento del búfer, pero solo manifestado al procesar datos internos que no pueden ser influenciados por el usuario).

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.