Vulnerabilidades

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

Matrix es un ecosistema para la Mensajería Instantánea federada abierta y voz sobre IP. En versiones 1.41.0 y anteriores, unos usuarios no autorizados pueden acceder a la membresía (lista de miembros, con sus nombres para mostrar) de una sala si conocen el ID de la misma. La vulnerabilidad es limitada a las salas con visibilidad del historial "shared". Además, el usuario no autorizado debe estar usando una cuenta en un servidor doméstico vulnerable que esté en la sala. Los administradores de servidores deben actualizar a versión 1.41.1 o posterior para recibir el parche. Se presenta una solución disponible. Los administradores de servidores que usan un proxy inverso podrían, con una pérdida de funcionalidad potencialmente inaceptable, bloquear los endpoints: "/_matrix/client/r0/rooms/{room_id}/members" con el parámetro de consulta "at", y "/_matrix/client/unstable/rooms/{room_id}/members" con el parámetro de consulta "at"

Se ha encontrado un fallo en libssh en versiones anteriores a 0.9.6. El protocolo SSH mantiene un registro de dos secretos compartidos durante el tiempo de la sesión. Uno de ellos se llama secret_hash y el otro session_id. Inicialmente, ambos son el mismo, pero después del recambio de claves, el session_id anterior es mantenida y usada como entrada para el nuevo secret_hash. Históricamente, ambos búferes tenían una variable de longitud compartida, que funcionaba mientras estos búferes eran iguales. Pero la operación de recambio de claves también puede cambiar el método de intercambio de claves, que puede ser basado en un hash de diferente tamaño, creando eventualmente "secret_hash" de diferente tamaño que el session_id presenta. Esto se convierte en un problema cuando la memoria de session_id se pone a cero o cuando es usada de nuevo durante el segundo intercambio de claves

"@npmcli/arborist", la librería que calcula los trees de dependencia y maneja la jerarquía de carpetas "node_modules" para la interfaz de línea de comandos de npm, presenta como objetivo garantizar que los contratos de dependencia de los paquetes se cumplan, y que la extracción de los contenidos de los paquetes sea llevada a cabo siempre en la carpeta esperada. Esto es conseguido, en parte, al resolver los especificadores de dependencia definidos en los manifiestos "package.json" para las dependencias con un nombre específico, y anidando las carpetas para resolver las dependencias conflictivas. Cuando las dependencias múltiples difieren sólo en el caso de su nombre, la estructura de datos interna de Arborist las veía como elementos separados que podían coexistir dentro del mismo nivel en la jerarquía "node_modules". Sin embargo, en los sistemas de archivos que no distinguen entre mayúsculas y minúsculas (como macOS y Windows), esto no es así. Combinado con una dependencia de symlink como "file:/some/path", esto permitía a un atacante crear una situación en la que se podían escribir contenidos arbitrarios en cualquier ubicación del sistema de archivos. Por ejemplo, un paquete "pwn-a" podría definir una dependencia en su archivo "package.json" como ""foo": "file:/some/path"". Otro paquete, "pwn-b" podría definir una dependencia como "FOO: "file:foo.tgz"". En los sistemas de archivos que no distinguen entre mayúsculas y minúsculas, si se instalara "pwn-a" y luego se instalara "pwn-b", el contenido de "foo.tgz" se escribiría en "/some/path", y cualquier contenido existente de "/some/path" se eliminaría. Cualquiera usando npm versiones v7.20.6 o anteriores en un sistema de archivos que no distinga entre mayúsculas y minúsculas está potencialmente afectado. Esto está parcheado en @npmcli/arborist 2.8.2 que se incluye en npm versiones v7.20.7 y superiores

El paquete npm "tar" (también se conoce como node-tar) versiones anteriores a 4.4.16, 5.0.8 y 6.1.7, 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 evitar llamadas innecesarias a las estadísticas para determinar si una ruta dada es un directorio, las rutas son almacenadas en caché cuando los directorios son creados. Esta lógica era insuficiente cuando se extraían archivos tar que contenían tanto un directorio como un enlace simbólico con el mismo nombre que el directorio, donde los nombres de los enlaces simbólicos y de los directorios en la entrada del archivo usaban barras invertidas como separador de rutas en los sistemas posix. La lógica de comprobación de la caché usaba tanto los caracteres "\" como "/" como separadores de ruta, sin embargo "\" es un carácter de nombre de archivo válido en los sistemas posix. Al crear primero un directorio, y luego sustituyendo ese directorio por un enlace simbólico, era posible omitir las comprobaciones de enlaces simbólicos de node-tar en los directorios, permitiendo esencialmente que un archivo tar no confiable hiciera 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. Además, una confusión similar podría surgir en los sistemas de archivos que no distinguen entre mayúsculas y minúsculas. Si un archivo tar contiene un directorio en "FOO", seguido de un enlace simbólico llamado "foo", entonces en los sistemas de archivos no sensibles a las mayúsculas y minúsculas, la creación del enlace simbólico eliminaría el directorio del sistema de archivos, pero no de la caché interna de directorios, ya que no se trataría como un golpe de caché. Una entrada de archivo posterior dentro del directorio "FOO" se colocaría entonces en el objetivo del enlace simbólico, pensando que el directorio ya había sido creado. Estos problemas se han solucionado en las versiones 4.4.16, 5.0.8 y 6.1.7. 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-9r2w-394v-53qc

Se ha detectado una Vulnerabilidad de Escalada de Privilegios por inyección SQL en la plataforma Orion, reportada por el Equipo de ZDI. Una inyección SQL booleana ciega que podría conllevar a una lectura y escritura completa sobre el contenido de la base de datos de Orion, incluyendo el certificado de Orion, para cualquier usuario autenticado

Tizen RT RTOS versión 3.0.GBB, es vulnerable a una envoltura de enteros en las funciones functions_calloc y mm_zalloc. Esta asignación de memoria inapropiada puede conllevar a una asignación de memoria arbitraria, resultando en un comportamiento inesperado, como un bloqueo

Una vulnerabilidad encontrada en la aplicación UniFi Protect versiones V1.18.1 y anteriores, permite a un actor malicioso que ya ha conseguido acceso a una red controlar posteriormente la(s) cámara(s) Protect asignada(s) a dicha red. Esta vulnerabilidad es corregida en la aplicación UniFi Protect versiones V1.19.0 y posteriores