Vulnerabilidades

Una Autorización Inapropiada en múltiples funciones en MIK.starlight versión 7.9.5.24363, permite a un atacante autenticado escalar privilegios

Se ha detectado un problema en OpenStack Neutron versiones anteriores a 16.4.1, 17.x versiones anteriores a 17.2.1 y 18.x versiones anteriores a 18.1.1. Unos atacantes autenticados pueden reconfigurar dnsmasq por medio de un valor extra_dhcp_opts diseñado

Se presenta una vulnerabilidad de tipo cross-site scripting (XSS) almacenado en FileBrowser versiones anteriores a v2.16.0, que permite a un usuario autenticado y autorizado cargar un archivo .svg malicioso que actúa como carga útil de tipo XSS almacenado. Si esta carga útil de tipo XSS almacenado es desencadenada por un administrador, activará comandos maliciosos del Sistema Operativo en el servidor ejecutando la instancia de FileBrowser

detect-character-encoding es un paquete para detectar la codificación de caracteres usando ICU. En detect-character-encoding versiones v0.3.0 y anteriores, la memoria asignada no es liberada. El problema ha sido parcheado en detect-character-encoding versión v0.3.1

Un uso de una clave criptográfica embebida en MIK.starlight versión 7.9.5.24363, permite a usuarios locales descifrar credenciales por medio de vectores no especificados

La función AdminGetFirstFileContentByFilePath en MIK.starlight versión 7.9.5.24363, permite (por diseño) a un atacante autenticado leer archivos arbitrarios del sistema de archivos al especificar la ruta del archivo

OpenOLAT es un sistema de administración de aprendizaje basado en la web (LMS). Se presenta una vulnerabilidad de salto de ruta en las versiones anteriores a 15.3.18, 15.5.3 y 16.0.0. Al usar un archivo ZIP especialmente preparado, es posible sobrescribir cualquier archivo que sea escribible por el usuario del servidor de aplicaciones (por ejemplo, el usuario tomcat). Dependiendo de la configuración, esto puede ser limitado a archivos del directorio de datos del usuario de OpenOlat, sin embargo, si no se configura apropiadamente, el ataque también podría ser usado para sobrescribir los archivos de configuración del servidor de aplicaciones, el código java o incluso los archivos del sistema operativo. El ataque podría ser usado para corromper o modificar cualquier archivo de OpenOlat, como las estructuras de los cursos, los archivos de configuración o los datos temporales de las pruebas. Estos ataques requerirían un conocimiento profundo de la instalación y por lo tanto más teórico. Si la configuración del servidor de aplicaciones permite la ejecución de archivos jsp y se conoce la ruta del contexto, también es posible ejecutar código java. Si el servidor de aplicaciones se ejecuta con el mismo usuario que es usado para desplegar el código OpenOlat o presenta permisos de escritura en los archivos de código OpenOlat y se conoce la ruta al contexto, es posible una inyección de código. El ataque requiere que una cuenta de usuario de OpenOlat cargue un archivo ZIP y desencadene el método de descompresión. No puede ser explotado por usuarios no registrados. El problema está corregido en versiones 15.3.18, 15.5.3 y 16.0.0. No se conocen soluciones aparte de la actualización

Una deserialización de datos no confiables en múltiples funciones en MIK.starlight 7.9.5.24363, permite a atacantes remotos autenticados ejecutar comandos del sistema operativo al diseñar objetos serializados

HashiCorp Vault Enterprise versiones 0.9.2 hasta 1.6.2, permitía la lectura de metadatos de licencia de DR secundarios sin autenticación. Corregido en versión 1.6.3

El paquete npm "tar" (también se conoce como node-tar) versiones anteriores a 4.4.18, 5.0.10 y 6.1.9, presenta una vulnerabilidad de creación y escritura excesiva de archivos arbitrarios y de ejecución de código arbitrario. node-tar pretende garantizar que no se extraiga ningún archivo cuya ubicación esté fuera del directorio de destino de la extracción. Esto es conseguido, en parte, al sanear las rutas absolutas de las entradas dentro del archivo, omitiendo las entradas del archivo que contienen porciones de ruta ".." y resolviendo las rutas saneadas contra el directorio de destino de la extracción. Esta lógica era insuficiente en los sistemas Windows cuando se extraían archivos tar que contenían una ruta que no era una ruta absoluta, sino que especificaba una letra de unidad diferente del destino de extracción, como "C:some\path". Si la letra de la unidad no coincide con el destino de la extracción, por ejemplo, "D:\extraction\dir", entonces el resultado de "path.resolve(extractionDirectory, entryPath)" se resolvería contra el directorio de trabajo actual en la unidad "C:", en lugar del directorio de destino de la extracción. Además, una porción ".." de la ruta podía aparecer inmediatamente después de la letra de la unidad, como "C:../foo", y no era saneada apropiadamente por la lógica que buscaba ".." dentro de las porciones normalizadas y divididas de la ruta. Esto sólo afecta a los usuarios de "node-tar" en sistemas Windows. Estos problemas se han solucionado en las versiones 4.4.18, 5.0.10 y 6.1.9. La rama v3 de node-tar ha quedado obsoleta y no ha recibido parches para estos problemas. Si todavía está usando una versión v3 le recomendamos que actualice a una versión más reciente de node-tar. No hay una forma razonable de solucionar este problema sin llevar a cabo los mismos procedimientos de normalización de rutas que hace ahora node-tar. Se recomienda a los usuarios que actualicen a las últimas versiones parcheadas de node-tar, en lugar de intentar sanear las rutas por sí mismos

El paquete npm "tar" (también se conoce como node-tar) versiones anteriores a 4.4.18, 5.0.10 y 6.1.9, presenta una vulnerabilidad de creación y escritura excesiva de archivos arbitrarios y de ejecución de código arbitrario. node-tar pretende garantizar que no se extraiga ningún archivo cuya ubicación sería modificada por un enlace simbólico. Esto es conseguido, en parte, asegurando que los directorios extraídos no sean enlaces simbólicos. Además, para prevenir llamadas innecesarias a las estadísticas para determinar si una ruta dada es un directorio, las rutas son almacenadas en caché cuando se crean los directorios. Esta lógica era insuficiente cuando se extraían archivos tar que contenían tanto un directorio como un enlace simbólico con nombres que contenían valores unicode que se normalizaban al mismo valor. Además, en los sistemas Windows, las partes de la ruta larga se resolvían a las mismas entidades del sistema de archivos que sus homólogos de la "ruta corta" de la versión 8.3. Un archivo tar especialmente diseñado podría incluir un directorio con una forma de la ruta, seguido de un enlace simbólico con una cadena diferente que resuelve a la misma entidad del sistema de archivos, seguido de un archivo usando la primera forma. Al crear primero un directorio, y luego reemplazando ese directorio con un enlace simbólico que tuviera un nombre aparente diferente que resolviera a la misma entrada en el sistema de archivos, era posible así omitir las comprobaciones de enlaces simbólicos de node-tar en los directorios, permitiendo esencialmente que un archivo tar no confiable tuviera un enlace simbólico en una ubicación arbitraria y que posteriormente extrajera archivos arbitrarios en esa ubicación, permitiendo así la creación y escritura excesiva arbitraria de archivos. Estos problemas se solucionaron en las versiones 4.4.18, 5.0.10 y 6.1.9. La rama v3 de node-tar ha quedado obsoleta y no ha recibido parches para estos problemas. Si todavía está usando una versión v3, le recomendamos que actualice a una versión más reciente de node-tar. Si esto no es posible, hay una solución disponible en la referencia GHSA-qq89-hq3f-393p

"@npmcli/arborist", la biblioteca que calcula los árboles de dependencia y maneja la jerarquía de carpetas node_modules para la interfaz de línea de comandos de npm, tiene como objetivo garantizar que se cumplan los contratos de dependencia de los paquetes, y que la extracción del contenido de los paquetes sea llevada a cabo siempre en la carpeta esperada. Esto es conseguido extrayendo el contenido de los paquetes en la carpeta "node_modules" de un proyecto. Si la carpeta "node_modules" del proyecto root o cualquiera de sus dependencias se sustituye de algún modo por un enlace simbólico, podría permitir a Arborist escribir las dependencias de los paquetes en cualquier ubicación arbitraria del sistema de archivos. Tenga en cuenta que los enlaces simbólicos contenidos en los artefactos de los paquetes se filtran, por lo que habría que emplear otro medio para crear un enlace simbólico "node_modules". 1. Un script "preinstall" podría sustituir "node_modules" por un enlace simbólico. (Esto es impedido usando "--ignore-scripts".) 2. Un atacante podría suministrar al objetivo un repositorio git, indicándole que ejecute "npm install --ignore-scripts" en root. Esto podría tener éxito, porque "npm install --ignore-scripts" no suele ser capaz de realizar cambios fuera del directorio del proyecto, por lo que podría considerarse seguro. Esto está parcheado en @npmcli/arborist versión 2.8.2 que se incluye en npm versiones v7.20.7 y superiores. Para más información, incluyendo soluciones, consulte la referencia documento GHSA-gmw6-94gg-2rc2