Fedor Indutny, autor de la plataforma Io.js (una bifurcación de Node.js), miembro del comité técnico que gestiona el desarrollo de Node.js, intentó llamar la atención sobre el problema de asignar identificadores CVE a nombres incorrectos. informes de vulnerabilidad, falsos o inadecuados que representen el nivel de peligro. El número CVE utilizado para identificar una vulnerabilidad se asigna sin una verificación adecuada y sin consultar a los desarrolladores de programas vulnerables, lo que conduce a abusos en los que se presentan errores menores bajo la apariencia de vulnerabilidades peligrosas, pero que en realidad no representan una amenaza para la seguridad.
Los CVE falsos no solo dañan la reputación de los proyectos, sino que también crean una carga adicional significativa para los mantenedores que tienen que clasificar flujos de correos electrónicos y mensajes que hacen referencia a dichos CVE. Lo más desagradable en tales situaciones es que los desarrolladores no pueden cuestionar el nivel de gravedad asignado ni conseguir que se revoque el CVE.
En el caso de Fedor, el problema afectó a la biblioteca Node.js node-ip, que antes de la publicación del informe de vulnerabilidad se descargaba aproximadamente 30 millones de veces por semana, pero en 5 meses el número de descargas se redujo a 17 millones por semana. Se cree que la presencia del informe de vulnerabilidad crítica contribuyó a la pérdida de popularidad de la biblioteca.
La biblioteca node-ip se utiliza como dependencia en más de 3500 proyectos, que cuando se compilan debido a un CVE falso, emiten una advertencia al ejecutar el comando "npm audit".
El flujo de quejas y mensajes relacionados con el CVE falso llevó al hecho de que después de varios meses de intentos de lograr cambios en el nivel de peligro en el CVE, el desarrollador de Node-IP cambió el repositorio del proyecto al modo de archivo, congelando el proceso de desarrollo. (el repositorio estuvo en modo de archivo durante 5 días y se eliminó varias horas).
La información sobre la vulnerabilidad CVE-2023-42282 se publicó a principios de febrero, pero antes de eso, el investigador que identificó el problema ha estado tratando de obtener una recompensa en la plataforma Huntr desde diciembre de 2022 (el nivel de gravedad probablemente esté sobreestimado porque afecta la premio). A juzgar por la información del informe de vulnerabilidad, los representantes de Huntr intentaron contactar a los desarrolladores de node-ip durante más de un año para solucionar el problema y solo entonces revelaron los detalles públicamente.
El problema es que las funciones isPublic() e isPrivate() de la biblioteca solo manejan la representación canónica. direcciones IPEsto puede generar resultados incorrectos al comprobar si una dirección se encuentra dentro de los rangos internos (10.xxx, 192.168.xx, 127.xxx, 172.16-31.xx) al transmitir una dirección en otros formatos, como 0x7f.1 y 127.1 en lugar de 127.0.0.1. Se afirmó que este problema podría utilizarse para eludir la protección SSRF y las comprobaciones de acceso a recursos. La CVE asignó al problema un nivel de gravedad crítico (9.8 sobre 10) y el informe de GitHub lo calificó como peligroso.
El autor de node-ip discrepó con la idea de que el problema constituyera una vulnerabilidad peligrosa. En concreto, para ejecutar un ataque, es necesario pasar un valor personalizado a las funciones isPublic() e isPrivate(), mientras que la información sobre la dirección IP del cliente que se conecta suele obtenerse de funciones del sistema o de una variable de entorno. servidores web, que inicialmente solo devuelven valores válidos. La posibilidad de que se transmitan datos no verificados sobre la dirección IP que se está verificando mediante formularios de entrada externos o fuentes controladas por el atacante parece especulativa.
Debido a la gran cantidad de solicitudes de correcciones, a mediados de febrero se crearon versiones correctivas de node-ip 1.1.9 y 2.0.1, en las que se agregaron verificaciones teniendo en cuenta formas atípicas de representación de direcciones IP. Sin embargo, dada la popularidad del proyecto, el flujo de mensajes relacionados y solicitudes de los usuarios no se ha detenido. En la base de datos MITRE, la vulnerabilidad sigue marcada como crítica, pero los representantes de GitHub se convencieron de reducir al mínimo el nivel de peligro en la base de datos de asesoramiento de GitHub.
Entre los informes recientes sobre un nivel de peligro sobreestimado, también se puede destacar la vulnerabilidad en LibreOffice 24.2.4 CVE-2024-5261, a la que se le asigna un nivel de peligro crítico (10 de 10). Problema,
solucionado hace unos días, afecta a la biblioteca LibreOfficeKit, que le permite acceder a las capacidades de LibreOffice desde aplicaciones externas C/C++, por ejemplo, llamando a funciones para conversión de formato. La esencia de la vulnerabilidad está en el uso de la configuración libCurl predeterminada (CURLOPT_SSL_VERIFYPEER=0), que deshabilita la verificación de certificados al cargar recursos externos a través de HTTPS, por ejemplo, imágenes externas especificadas en el documento.
Fuente: opennet.ru
