Vulnerabilidades

SquaredUp DS para SCOM 6.2.1.11104 permite XSS.

Pagefind, una librería de búsqueda completamente estática, inicializa sus archivos dinámicos de JavaScript y WebAssembly en relación con la ubicación del primer script que carga el usuario. Esta información se obtiene buscando el valor de `document.currentScript.src`. Antes de la versión 1.1.1 de Pagefind, era posible "bloquear" esta búsqueda con HTML benigno en la página. Esto hará que `document.currentScript.src` se resuelva como un dominio externo, que luego será utilizado por Pagefind para cargar dependencias. Esta vulnerabilidad solo funcionaría en el caso de que un atacante pudiera inyectar HTML en un sitio web alojado y en vivo. En estos casos, esto actuaría como una forma de escalar el privilegio disponible para un atacante. Esto supone que tienen la capacidad de agregar algunos elementos a la página (por ejemplo, etiquetas `img` con un atributo `name`), pero no otros, ya que agregar un `script` a la página sería en sí mismo el vector de cross-site scripting. Pagefind ha mejorado esta resolución en la versión 1.1.1 al garantizar que la fuente se cargue desde un elemento de script válido. No hay informes de que esto se haya explotado en la práctica a través de Pagefind.

@blakeembrey/template es una librería de plantillas de cadenas. Antes de la versión 1.2.0, era posible inyectar y ejecutar código dentro de la plantilla si el atacante tenía acceso para escribir el nombre de la plantilla. La versión 1.2.0 contiene un parche. Como workaround, no pase una entrada que no sea de confianza como nombre para mostrar de la plantilla o no use la función de nombre para mostrar.

Los dispositivos Yubico YubiKey 5 Series con firmware anterior a la versión 5.7.0 y los dispositivos YubiHSM 2 con firmware anterior a la versión 2.4.0 permiten un ataque de extracción de clave secreta ECDSA (que requiere acceso físico y equipo costoso) en el que está presente un canal lateral electromagnético debido a una inversión modular de tiempo no constante para el algoritmo euclidiano extendido, también conocido como el problema EUCLEAK. También pueden verse afectados otros usos de una librería criptográfica de Infineon.

Tina es un sistema de gestión de contenido (CMS) de código abierto. Los sitios creados con la interfaz de línea de comandos (CLI) de Tina CMS anterior a la versión 1.6.2 que utilizan un token de búsqueda pueden ser vulnerables a que el token de búsqueda se filtre a través del archivo de bloqueo (tina-lock.json). Los administradores de sitios web habilitados para Tina con configuración de búsqueda deben rotar su clave de inmediato. Este problema se ha corregido en la versión 1.6.2 de @tinacms/cli. Es necesario actualizar y rotar el token de búsqueda para solucionarlo correctamente.

Se descubrió que PingCAP TiDB v8.1.0 contenía un desbordamiento de búfer a través del componente (*Column).GetDecimal. Esto permite a los atacantes provocar una denegación de servicio (DoS) a través de una entrada manipulada para 'RemoveUnnecessaryFirstRow', que comprobará la expresión entre 'Agg' y 'GroupBy', pero no comprobará el tipo de retorno.

SudoBot, un bot de moderación de Discord, es vulnerable a la escalada de privilegios y al exploit del comando `-config` en versiones anteriores a la 9.26.7. En teoría, cualquiera puede actualizar cualquier configuración del bot y potencialmente obtener control sobre las configuraciones del bot. Todas las versiones de v9 anteriores a la v9.26.7 están afectadas. Otras versiones (por ejemplo, v8) no están afectadas. Los usuarios deben actualizar a la versión 9.26.7 para recibir un parche. Un workaround sería crear una sobrescritura de permiso de comando en la base de datos. Se puede ejecutar una declaración SQL provista en el Asesor de seguridad de GitHub para crear una sobrescritura que no permita a los usuarios sin permiso `ManageGuild` ejecutar el comando `-config`. Ejecute la declaración SQL para cada servidor en el que esté el bot y reemplace `` con el ID de gremio apropiado cada vez.

runc es una herramienta CLI para generar y ejecutar contenedores de acuerdo con la especificación OCI. runc 1.1.13 y anteriores, así como 1.2.0-rc2 y anteriores, pueden ser engañados para crear archivos o directorios vacíos en ubicaciones arbitrarias en el sistema de archivos del host al compartir un volumen entre dos contenedores y explotar una ejecución con `os.MkdirAll`. Si bien esto podría usarse para crear archivos vacíos, los archivos existentes no se truncarían. Un atacante debe tener la capacidad de iniciar contenedores utilizando algún tipo de configuración de volumen personalizada. Los contenedores que utilizan espacios de nombres de usuario aún se ven afectados, pero el alcance de los lugares en los que un atacante puede crear inodos se puede reducir significativamente. Las políticas LSM suficientemente estrictas (SELinux/Apparmor) también pueden, en principio, bloquear este ataque; sospechamos que la política SELinux estándar de la industria puede restringir el alcance de este ataque, pero no se ha analizado el alcance exacto de la protección. Esto se puede explotar utilizando runc directamente, así como a través de Docker y Kubernetes. El problema se ha solucionado en runc v1.1.14 y v1.2.0-rc3. Hay algunos workarounds disponibles. El uso de espacios de nombres de usuario restringe este ataque de forma bastante significativa, de modo que el atacante solo puede crear inodos en directorios a los que el usuario o grupo raíz reasignado tiene acceso de escritura. A menos que el usuario raíz se reasigne a un usuario real en el host (como con contenedores sin raíz que no usan `/etc/sub[ug]id`), esto en la práctica significa que un atacante solo podría crear inodos en directorios con permisos de escritura para todo el mundo. Una política de SELinux o AppArmor lo suficientemente estricta podría, en principio, restringir también el alcance si se aplica una etiqueta específica al entorno de ejecución de runc, aunque ni el grado en el que las políticas estándar existentes bloquean este ataque ni qué políticas exactas se necesitan para restringirlo lo suficiente se han probado exhaustivamente.runc es una herramienta CLI para generar y ejecutar contenedores de acuerdo con la especificación OCI. runc 1.1.13 y anteriores, así como 1.2.0-rc2 y anteriores, pueden ser engañados para crear archivos o directorios vacíos en ubicaciones arbitrarias en el sistema de archivos del host al compartir un volumen entre dos contenedores y explotar una ejecución con `os.MkdirAll`. Si bien esto podría usarse para crear archivos vacíos, los archivos existentes no se truncarían. Un atacante debe tener la capacidad de iniciar contenedores utilizando algún tipo de configuración de volumen personalizada. Los contenedores que utilizan espacios de nombres de usuario aún se ven afectados, pero el alcance de los lugares en los que un atacante puede crear inodos se puede reducir significativamente. Las políticas LSM suficientemente estrictas (SELinux/Apparmor) también pueden, en principio, bloquear este ataque; sospechamos que la política SELinux estándar de la industria puede restringir el alcance de este ataque, pero no se ha analizado el alcance exacto de la protección. Esto se puede explotar utilizando runc directamente, así como a través de Docker y Kubernetes. El problema se ha solucionado en runc v1.1.14 y v1.2.0-rc3. Hay algunos workarounds disponibles. El uso de espacios de nombres de usuario restringe este ataque de forma bastante significativa, de modo que el atacante solo puede crear inodos en directorios a los que el usuario o grupo raíz reasignado tiene acceso de escritura. A menos que el usuario raíz se reasigne a un usuario real en el host (como con contenedores sin raíz que no usan `/etc/sub[ug]id`), esto en la práctica significa que un atacante solo podría crear inodos en directorios con permisos de escritura para todo el mundo. --- truncado -----

Xibo es una plataforma de señalización digital de código abierto con un sistema de gestión de contenido web (CMS). Antes de la versión 4.1.0, una vulnerabilidad de cross-site scripting en Xibo CMS permitía a los usuarios autorizados ejecutar JavaScript a través de la funcionalidad DataSet. Los usuarios pueden diseñar un DataSet con una columna HTML que contenga JavaScript, que es la funcionalidad prevista. El JavaScript se ejecuta en la página de entrada de datos y en cualquier diseño que haga referencia a él. Este comportamiento se ha modificado en la versión 4.1.0 para mostrar HTML/CSS/JS como código en la página de entrada de datos. No existen workarounds para este problema.

Bare Metal Operator (BMO) implementa una API de Kubernetes para administrar hosts de bare metal en Metal3. El CRD `BareMetalHost` (BMH) permite que `userData`, `metaData` y `networkData` para el host aprovisionado se especifiquen como enlaces a secretos de Kubernetes. Hay campos tanto para el `Name` como para el `Namespace` del secreto, lo que significa que las versiones del baremetal-operator anteriores a 0.8.0, 0.6.2 y 0.5.2 leerán un `Secret` de cualquier espacio de nombres. Un usuario con acceso para crear o editar un `BareMetalHost` puede, por lo tanto, exfiltrar un `Secret` de otro espacio de nombres al usarlo, por ejemplo, como `userData` para aprovisionar algún host (tenga en cuenta que no es necesario que sea un host real, podría ser una máquina virtual en algún lugar). BMO solo leerá una clave con el nombre `value` (o `userData`, `metaData` o `networkData`), por lo que limita un poco la exposición. `value` es probablemente una clave bastante común. Los secretos utilizados por _otros_ `BareMetalHost` en diferentes espacios de nombres siempre son vulnerables. Es probablemente relativamente inusual que alguien que no sea un administrador del clúster tenga acceso RBAC para crear o editar un `BareMetalHost`. Esta vulnerabilidad solo es significativa si el clúster tiene usuarios que no sean administradores y los privilegios de los usuarios están limitados a sus respectivos espacios de nombres. El parche evita que BMO acepte enlaces a secretos de otros espacios de nombres como entrada BMH. Cualquier configuración de BMH solo se lee desde el mismo espacio de nombres. El problema está parcheado en las versiones v0.7.0, v0.6.2 y v0.5.2 de BMO y los usuarios deben actualizar a esas versiones. Antes de actualizar, duplique los secretos de BMC en el espacio de nombres donde se encuentra el BMH correspondiente. Después de la actualización, elimine los secretos antiguos. Como solución alternativa, un operador puede configurar BMO RBAC para que tenga alcance de espacio de nombres para secretos, en lugar de alcance de clúster, para evitar que BMO acceda a secretos desde otros espacios de nombres.

Se descubrió que ClickHouse v24.3.3.102 contenía un desbordamiento de búfer a través del componente DB::evaluateConstantExpressionImpl.

Se descubrió que YugabyteDB v2.21.1.0 contenía un desbordamiento de búfer a través del parámetro "insertar en".