Vulnerabilidades

Múltiples servicios del DUT así como diferentes ámbitos del mismo servicio reutilizan las mismas credenciales.

Varias credenciales para la base de datos PostgreSQL local se almacenan en texto sin formato (parcialmente codificado en base64).

La aplicación es vulnerable a ataques de inyección SQL. Un atacante puede volcar la base de datos PostgreSQL y leer su contenido.

Las variables de entorno del sistema se registran en los registros de diagnóstico de Docker Desktop al usar el autocompletado del shell. Esto provoca la divulgación involuntaria de información confidencial, como claves de API, contraseñas, etc. Un agente malicioso con acceso de lectura a estos registros podría obtener secretos y utilizarlos para obtener acceso no autorizado a otros sistemas. A partir de la versión 4.43.0, Docker Desktop ya no registra las variables de entorno del sistema como parte de la recopilación de registros de diagnóstico.

Una vulnerabilidad de autorización incorrecta en OpenText™ GroupWise permite explotar niveles de seguridad de control de acceso configurados incorrectamente. Esta vulnerabilidad podría permitir el acceso no autorizado a elementos del calendario marcados como privados. Este problema afecta a las versiones 7 a 17.5, 23.4, 24.1, 24.2, 24.3 y 24.4 de GroupWise.

Varios complementos para WordPress son vulnerables a Cross-Site Scripting Almacenado a través de la librería Magnific Popups (versión 1.1.0) incluida en el complemento en varias versiones, debido a una depuración de entrada insuficiente y al escape de salida en los atributos proporcionados por el usuario. Esto permite a atacantes autenticados, con acceso de colaborador o superior, inyectar scripts web arbitrarios en páginas que se ejecutarán al acceder un usuario a una página inyectada. NOTA: Esta vulnerabilidad se corrigió en la librería original (Magnific Popups versión 1.2.0) al deshabilitar la carga de HTML en ciertos campos por defecto.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: crypto: marvell/cesa - Gestionar solicitudes skcipher de longitud cero. No acceder a memoria aleatoria para solicitudes skcipher de longitud cero. Simplemente devolver 0.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: evitar el uso de múltiples dispositivos con diferentes tipos Para múltiples dispositivos, tanto los dispositivos principales como los adicionales deben ser del mismo tipo. `erofs_init_device` ya ha garantizado que si el principal es un dispositivo respaldado por archivos, los dispositivos adicionales también deben ser archivos normales. Sin embargo, si el dispositivo principal es un dispositivo de bloque mientras que el dispositivo adicional es un dispositivo respaldado por archivo, `erofs_init_device` obtendrá un ENOTBLK, que no se trata como un error en `erofs_fc_get_tree`, y eso lleva a un UAF: erofs_fc_get_tree get_tree_bdev_flags(erofs_fc_fill_super) erofs_read_superblock erofs_init_device // sbi->dif0 aún no se ha inicializado, // return -ENOTBLK deactivate_locked_super free(sbi) if (err is -ENOTBLK) sbi->dif0.file = filp_open() // sbi UAF Entonces, si se alcanza -ENOTBLK en `erofs_init_device`, significa que el dispositivo principal debe ser un dispositivo de bloque y el dispositivo adicional no es un dispositivo de bloque. El error se puede convertir a -EINVAL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: power: supply: max77705: Se ha corregido el manejo de errores de la cola de trabajo en la sonda. La función create_singlethread_workqueue() no devuelve punteros de error, sino NULL. También se ha corregido la cola de trabajo en las rutas de error.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: arm64/fpsimd: Evite afectar negativamente al estado FPSIMD del kernel con SMSTOP En sistemas con SMSTOP, el estado FPSIMD del kernel de un subproceso puede verse afectado negativamente durante un cambio de contexto inmediatamente después de restaurarse dicho estado. Los sistemas sin SMSTOP no se ven afectados. Si la CPU está en modo SVE de transmisión antes de un cambio de contexto a un subproceso con estado FPSIMD del kernel, fpsimd_thread_switch() restaurará el estado FPSIMD del kernel mediante fpsimd_load_kernel_state() mientras la CPU sigue en modo SVE de transmisión. Cuando fpsimd_thread_switch() llama posteriormente a fpsimd_flush_cpu_state(), se ejecutará un SMSTOP, lo que provocará la salida del modo SVE de transmisión. La salida del modo SVE de transmisión provocará que el hardware restablezca varios registros FPSIMD/SVE/SME, afectando negativamente al estado FPSIMD. Solucione esto llamando a fpsimd_flush_cpu_state() antes de restaurar el estado FPSIMD del kernel.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: perf: arm-ni: Anular el registro de las PMU en caso de fallo de la sonda. Cuando falla la asignación de recursos en un dominio de reloj de un dispositivo NI, es necesario revertir correctamente todas las PMU de perf registradas previamente en otros dominios de reloj del mismo dispositivo. De lo contrario, puede provocar pánicos del kernel. Llamada a arm_ni_init+0x0/0xff8 [arm_ni] a 2374 arm-ni ARMHCB70:00: Error al solicitar la región de PMU 0x1f3c13000 arm-ni ARMHCB70:00: La sonda con el controlador arm-ni falló con el error -16. Corrupción de list_add: next->prev debería ser prev (ffffffd01e9698a18), pero era 0000000000000000. (next=ffff10001a0decc8). pstate: 6340009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : list_add_valid_or_report+0x7c/0xb8 lr : list_add_valid_or_report+0x7c/0xb8 Call trace: __list_add_valid_or_report+0x7c/0xb8 perf_pmu_register+0x22c/0x3a0 arm_ni_probe+0x554/0x70c [arm_ni] platform_probe+0x70/0xe8 really_probe+0xc6/0x4d8 driver_probe_device+0x48/0x170 __driver_attach+0x8e/0x1c0 bus_for_each_dev+0x64/0xf0 driver_add+0x138/0x260 bus_add_driver+0x68/0x138 __platform_driver_register+0x2c/0x40 arm_ni_init+0x14/0x2a [arm_ni] do_init_module+0x36/0x298 ---[ fin de seguimiento 000000000000000 ]--- Pánico del kernel - no sincroniza: Ups - ERROR: Excepción fatal SMP: deteniendo las CPU secundarias

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corregir pánico ktls con sockmap [ 2172.936997] ------------[ cortar aquí ]------------ [ 2172.936999] ERROR del kernel en lib/iov_iter.c:629! ...... [ 2172.944996] PKRU: 55555554 [ 2172.945155] Rastreo de llamadas: [ 2172.945299] [ 2172.945428] ? die+0x36/0x90 [ 2172.945601] ? do_trap+0xdd/0x100 [ 2172.945795] ? iov_iter_revert+0x178/0x180 [ 2172.946031] ? iov_iter_revert+0x178/0x180 [ 2172.946267] ? do_error_trap+0x7d/0x110 [ 2172.946499] ? iov_iter_revert+0x178/0x180 [ 2172.946736] ? exc_invalid_op+0x50/0x70 [ 2172.946961] ? iov_iter_revert+0x178/0x180 [ 2172.947197] ? asm_exc_invalid_op+0x1a/0x20 [ 2172.947446] ? iov_iter_revert+0x178/0x180 [ 2172.947683] ? iov_iter_revert+0x5c/0x180 [ 2172.947913] tls_sw_sendmsg_locked.isra.0+0x794/0x840 [ 2172.948206] tls_sw_sendmsg+0x52/0x80 [ 2172.948420] ? inet_sendmsg+0x1f/0x70 [ 2172.948634] __sys_sendto+0x1cd/0x200 [ 2172.948848] ? find_held_lock+0x2b/0x80 [ 2172.949072] ? syscall_trace_enter+0x140/0x270 [ 2172.949330] ? __lock_release.isra.0+0x5e/0x170 [ 2172.949595] ? find_held_lock+0x2b/0x80 [ 2172.949817] ? syscall_trace_enter+0x140/0x270 [ 2172.950211] ? lockdep_hardirqs_on_prepare+0xda/0x190 [ 2172.950632] ? ktime_get_coarse_real_ts64+0xc2/0xd0 [ 2172.951036] __x64_sys_sendto+0x24/0x30 [ 2172.951382] do_syscall_64+0x90/0x170 ...... Después de llamar a bpf_exec_tx_verdict(), el tamaño de msg_pl->sg puede aumentar, por ejemplo, cuando el programa BPF ejecuta bpf_msg_push_data(). Si el programa BPF define cork_bytes y sg.size es menor que cork_bytes, devolverá -ENOSPC e intentará revertir a la lógica de copia no nula. Sin embargo, durante la reversión, msg->msg_iter se restablece, pero como se ha aumentado msg_pl->sg.size, las ejecuciones posteriores superarán el tamaño real de msg_iter. ''' iov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size); ''' Los cambios en esta confirmación se basan en las siguientes consideraciones: 1. Cuando se establece cork_bytes, revertir a la lógica de copia no nula no tiene sentido y se puede pasar directamente a la lógica de copia cero. 2. No podemos calcular el número correcto de bytes para revertir msg_iter. Supongamos que los datos originales son "abcdefgh" (8 bytes) y, tras 3 intentos del programa BPF, se convierten en datos de 11 bytes: "abc?de?fgh?". Luego, configuramos cork_bytes en 6, lo que significa que los primeros 6 bytes se han procesado y los 5 bytes restantes de "?fgh?" se almacenarán en caché hasta que la longitud cumpla con el requisito de cork_bytes. Sin embargo, algunos datos en "?fgh?" no están dentro de 'sg->msg_iter' (sino en msg_pl), especialmente los datos "?" que enviamos. Por lo tanto, no parece tan sencillo como revertir a través de un desplazamiento de msg_iter. 3. Para sockets sin TLS en tcp_bpf_sendmsg, cuando se produce una situación de "cork", la función send() en el espacio de usuario no devuelve un error y la longitud devuelta es la misma que el parámetro de longitud de entrada, incluso si algunos datos están almacenados en caché. Además, observé que la lógica actual de copia distinta de cero para gestionar el cork se escribe así: ''' línea 1177 else if (ret != -EAGAIN) { if (ret == -ENOSPC) ret = 0; goto send_end; ''' Por lo tanto, está bien simplemente devolver 'copiado' sin error cuando ocurre una situación de "corcho".