Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: x86/sev: Expulsar líneas de caché durante la validación de memoria SNP Una vulnerabilidad de coherencia de caché SNP requiere una mitigación de expulsión de línea de caché al validar la memoria después de un cambio de estado de página a privado. La mitigación específica es tocar el primer y el último byte de cada página de 4K que se está validando. No es necesario realizar la mitigación cuando se realiza un cambio de estado de página a compartido y se rescinde la validación. El bit CPUID Fn8000001F_EBX[31] define el bit COHERENCY_SFW_NO CPUID que, cuando se establece, indica que no se necesita la mitigación de software para esta vulnerabilidad. Implemente la mitigación e invóquela al validar la memoria (haciéndola privada) y el bit COHERENCY_SFW_NO no está establecido, lo que indica que el invitado SNP es vulnerable.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: corrección del problema de use-after-free en composite_dev_cleanup(). 1. En la función configfs_composite_bind() -> composite_os_desc_req_prepare(): si kmalloc falla, el puntero cdev->os_desc_req se liberará, pero no se establecerá en NULL. En ese caso, devolverá un error a la función de nivel superior. 2. En la función configfs_composite_bind() -> composite_dev_cleanup(): comprobará si cdev->os_desc_req es NULL. Si no lo es, intentará usarlo. Esto provocará un problema de use-after-free. ERROR: KASAN: use-after-free en composite_dev_cleanup+0xf4/0x2c0 Lectura de tamaño 8 en la dirección 0000004827837a00 por la tarea init/1 CPU: 10 PID: 1 Comm: init Contaminado: GO 5.10.97-oh #1 kasan_report+0x188/0x1cc __asan_load8+0xb4/0xbc composite_dev_cleanup+0xf4/0x2c0 configfs_composite_bind+0x210/0x7ac udc_bind_to_driver+0xb4/0x1ec usb_gadget_probe_driver+0xec/0x21c gadget_dev_desc_UDC_store+0x264/0x27c

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: se corrige un UAF cuando vma->mm se libera después de que vma->vm_refcnt se eliminara. Al inducir retrasos en los lugares adecuados, Jann Horn creó un reproductor para un problema de UAF difícil de alcanzar que se hizo posible después de que se permitiera reciclar los VMA agregando SLAB_TYPESAFE_BY_RCU a su caché. La descripción de la ejecución se tomó prestada del informe de descubrimiento de Jann: lock_vma_under_rcu() busca un VMA sin bloqueo con mas_walk() bajo rcu_read_lock(). En ese punto, el VMA puede liberarse simultáneamente y puede reciclarse por otro proceso. vma_start_read() luego incrementa vma->vm_refcnt (si está en un rango aceptable) y, si esto tiene éxito, vma_start_read() puede devolver un VMA reciclado. En este escenario, donde el VMA se ha reciclado, lock_vma_under_rcu() detectará el puntero ->vm_mm no coincidente y eliminará el VMA mediante vma_end_read(), que llama a vma_refcount_put(). vma_refcount_put() elimina el recuento de referencias y luego llama a rcuwait_wake_up() usando una copia de vma->vm_mm. Esto es incorrecto: asume implícitamente que quien llama mantiene activo el mm del VMA, pero en este escenario, quien llama no tiene relación con el mm del VMA, por lo que rcuwait_wake_up() puede causar UAF. El diagrama que representa la ejecución: T1 T2 T3 == == == lock_vma_under_rcu mas_walk mmap vma_start_read __refcount_inc_not_zero_limited_acquire munmap __vma_enter_locked refcount_add_not_zero vma_end_read vma_refcount_put __refcount_dec_and_test rcuwait_wait_event rcuwait_wake_up [UAF] Tenga en cuenta que rcuwait_wait_event() en T3 no se bloquea porque refcount ya fue descartado por T1. En este punto, T3 puede salir y liberar el mm que causa UAF en T1. Para evitar esto, movemos la verificación vma->vm_mm a vma_start_read() y tomamos vma->vm_mm para estabilizarlo antes de la operación vma_refcount_put(). [surenb@google.com: v3]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: apple: validar el recuento de campos del informe de características para evitar la desreferencia de puntero NULL. Un dispositivo HID malicioso con la peculiaridad APPLE_MAGIC_BACKLIGHT puede activar una desreferencia de puntero NULL mientras el informe de características de potencia se conmuta y se envía al dispositivo en apple_magic_backlight_report_set(). Se espera que el informe de características de potencia tenga dos campos de datos, pero si el descriptor declara un campo, entonces acceder a field[1] y desreferenciarlo en apple_magic_backlight_report_set() se vuelve inválido ya que field[1] será NULL. Un ejemplo de un descriptor mínimo que puede causar el bloqueo es algo como lo siguiente, donde el informe con ID 3 (informe de potencia) solo hace referencia a un único campo de 1 byte. Cuando el núcleo hid analiza el descriptor, encontrará la etiqueta de característica final, asignará un hid_report (todos los miembros de field[] se pondrán a cero), creará una estructura de campo y la completará, aumentando el maxfield a 1. El acceso y la desreferencia a field[1] posteriores provocan el bloqueo. Página de uso (definida por el proveedor 0xFF00) Uso (0x0F) Recopilación (aplicación) ID de informe (1) Uso (0x01) Mínimo lógico (0) Máximo lógico (255) Tamaño de informe (8) Cantidad de informes (1) Característica (datos, variables, abs) Uso (0x02) Máximo lógico (32767) Tamaño de informe (16) Cantidad de informes (1) Característica (datos, variables, abs) ID de informe (3) Uso (0x03) Mínimo lógico (0) Máximo lógico (1) Tamaño de informe (8) Cantidad de informes (1) Característica (datos, variables, abs) Fin de recopilación Aquí vemos el splat de KASAN cuando el núcleo desreferencia el puntero NULL y se bloquea: [ 15.164723] Ups: fallo de protección general, probablemente para la dirección no canónica 0xdffffc0000000006: 0000 [#1] SMP KASAN NOPTI [ 15.165691] KASAN: null-ptr-deref en el rango [0x0000000000000030-0x0000000000000037] [ 15.165691] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 No contaminado 6.15.0 #31 PREEMPT(voluntario) [ 15.165691] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 [ 15.165691] RIP: 0010:apple_magic_backlight_report_set+0xbf/0x210 [ 15.165691] Rastreo de llamadas: [ 15.165691] [ 15.165691] apple_probe+0x571/0xa20 [ 15.165691] hid_device_probe+0x2e2/0x6f0 [ 15.165691] really_probe+0x1ca/0x5c0 [ 15.165691] __driver_probe_device+0x24f/0x310 [ 15.165691] driver_probe_device+0x4a/0xd0 [ 15.165691] __device_attach_driver+0x169/0x220 [ 15.165691] bus_for_each_drv+0x118/0x1b0 [ 15.165691] __device_attach+0x1d5/0x380 [ 15.165691] device_initial_probe+0x12/0x20 [ 15.165691] bus_probe_device+0x13d/0x180 [ 15.165691] device_add+0xd87/0x1510 [...] Para solucionar este problema debemos validar el número de campos que tienen los reportes de retroiluminación y energía y si no tienen el número de campos requerido entonces abandonar.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: HID: núcleo: Reforzar s32ton() contra la conversión a 0 bits. Las pruebas realizadas por el fuzzer syzbot mostraron que el núcleo HID recibe una excepción de desplazamiento fuera de los límites al intentar convertir una cantidad de 32 bits a una cantidad de 0 bits. Idealmente, esto nunca debería ocurrir, pero existen dispositivos con errores y algunos podrían tener un campo de informe con un tamaño establecido en cero; no deberíamos rechazar el informe ni el dispositivo solo por eso. En su lugar, reforzar la rutina s32ton() para que devuelva un resultado razonable en lugar de bloquearse al llamarla con el número de bits establecido en 0, igual que ocurre con snto32().

Razón rechazado: ** Rechazo ** No use este número de candidato. Razón: este candidato fue emitido por error. Notas: Todas las referencias y descripciones en este candidato se han eliminado para evitar el uso accidental.

Se ha detectado una vulnerabilidad de seguridad en Scada-LTS 2.7.8.1. Este problema afecta a un procesamiento desconocido del archivo view_edit.shtm del componente SVG File Handler. Esta manipulación del argumento backgroundImageMP provoca ataques de cross site scripting. El ataque puede ejecutarse en remoto. Se ha hecho público el exploit y puede que sea utilizado.

Se ha detectado una falla en el Linksys E5600 1.1.0.26. El elemento afectado es la función verify_gemtek_header del archivo checkFw.sh del componente Firmware Handler. La manipulación puede resultar en un algoritmo criptográfico arriesgado. El ataque puede ejecutarse en remoto. Requiere un alto nivel de complejidad. La explotabilidad se describe como difícil. Se contactó al proveedor con antelación sobre esta divulgación, pero no respondió.

Vulnerabilidad de cross site scripting (XSS) en Hustoj 2025-01-31 a través del parámetro TID en thread.php.

EzGED3 3.5.0 contiene una vulnerabilidad de lectura arbitraria de archivos sin autenticación debido a un control de acceso inadecuado y una validación de entrada insuficiente en un script expuesto a través de la interfaz web. Un atacante remoto puede proporcionar un parámetro de ruta manipulado a un script PHP para leer archivos arbitrarios del sistema de archivos. El script carece de comprobaciones de autenticación y gestión de rutas seguras, lo que permite ataques de salto de directorio (p. ej., ../../../) para acceder a archivos sensibles como archivos de configuración, volcados de bases de datos, código fuente y tokens de restablecimiento de contraseña. Si phpMyAdmin está expuesto, las credenciales extraídas pueden usarse para acceso administrativo directo. En entornos sin estas herramientas, las lecturas de archivos controladas por el atacante permiten la extracción completa de la base de datos al dirigirse a archivos de datos MySQL sin procesar. El proveedor afirma que el problema está corregido en la versión 3.5.72.27183.

EzGED3 3.5.0 almacena las contraseñas de los usuarios mediante un esquema de hash inseguro: md5(md5(contraseña)). Este método de hash es criptográficamente débil y permite a los atacantes realizar ataques de fuerza bruta sin conexión si se divulgan los hashes de las contraseñas. La ausencia de sal y el uso de un algoritmo rápido y obsoleto permiten recuperar credenciales de texto plano mediante tablas precalculadas o herramientas de descifrado basadas en GPU. El proveedor afirma que el problema está corregido en la versión 3.5.72.27183.

Se ha identificado un problema de seguridad en Appian Enterprise Business Process Management versión 25.3. La vulnerabilidad está relacionada con un control de acceso incorrecto, que en ciertas circunstancias podría permitir el acceso no autorizado a la información.