Vulnerabilidades

Una vulnerabilidad en el componente de registro de Cisco Duo Authentication para Windows Logon y RDP podría permitir que un atacante local autenticado vea información confidencial en texto sin cifrar en un sistema afectado. Esta vulnerabilidad se debe al almacenamiento inadecuado de una clave de registro no cifrada en ciertos registros. Un atacante podría aprovechar esta vulnerabilidad accediendo a los registros de un sistema afectado. Un exploit exitoso podría permitir al atacante ver información confidencial en texto sin cifrar.

Una vulnerabilidad en la autenticación de Cisco Duo para el inicio de sesión de Windows y RDP podría permitir que un atacante físico autenticado omita la autenticación secundaria y acceda a un dispositivo Windows afectado. Esta vulnerabilidad se debe a una falla al invalidar las sesiones confiables creadas localmente después de reiniciar el dispositivo afectado. Un atacante con credenciales de usuario principal podría aprovechar esta vulnerabilidad al intentar autenticarse en un dispositivo afectado. Un exploit exitoso podría permitir al atacante acceder al dispositivo afectado sin permisos válidos.

En Apache Linkis <= 1.4.0, la contraseña se imprime en el registro cuando se utiliza la fuente de datos de Oracle del módulo de fuente de datos de Linkis. Recomendamos a los usuarios actualizar la versión de Linkis a la versión 1.5.0

Vulnerabilidad de deserialización de datos no confiables en Apache InLong. Este problema afecta a Apache InLong: desde 1.8.0 hasta 1.10.0, los atacantes pueden usar el payload específica para leer desde un archivo arbitrario. Se recomienda a los usuarios actualizar a Apache InLong 1.11.0 o seleccionar [1] para resolverlo. [1] https://github.com/apache/inlong/pull/9673

En los productos Blue Planet® hasta la versión 22.12, una mala configuración en la implementación de SAML permite la escalada de privilegios. Sólo se ven afectados los productos que utilizan autenticación SAML. Blue Planet® ha lanzado actualizaciones de software que abordan esta vulnerabilidad para los productos afectados. Se recomienda a los clientes que actualicen sus productos Blue Planet a la última versión del software lo antes posible. Las actualizaciones de software se pueden descargar desde el Portal de soporte de Ciena.

Esta vulnerabilidad existe en USB Pratirodh debido al uso de un algoritmo criptográfico (hash) SHA1 más débil en el componente de inicio de sesión del usuario. Un atacante local con privilegios administrativos podría aprovechar esta vulnerabilidad para obtener la contraseña del USB Pratirodh en el sistema objetivo. La explotación exitosa de esta vulnerabilidad podría permitir al atacante tomar el control de la aplicación y modificar el control de acceso de los usuarios o dispositivos registrados en el sistema objetivo.

Esta vulnerabilidad existe en el software AppSamvid debido al uso de un algoritmo criptográfico (hash) SHA1 más débil en el componente de inicio de sesión del usuario. Un atacante con privilegios administrativos locales podría aprovechar esto para obtener la contraseña de AppSamvid en el sistema objetivo. La explotación exitosa de esta vulnerabilidad podría permitir al atacante tomar el control total de la aplicación en el sistema objetivo.

Esta vulnerabilidad existe en el software AppSamvid debido al uso de componentes vulnerables y obsoletos. Un atacante con privilegios administrativos locales podría aprovechar esto colocando archivos DLL maliciosos en el sistema objetivo. La explotación exitosa de esta vulnerabilidad podría permitir al atacante ejecutar código arbitrario en el sistema objetivo.

Vulnerabilidad almacenada de Cross-Site Scripting en Gophish que afecta a la versión 0.12.1. Esta vulnerabilidad podría permitir a un atacante almacenar un payload de JavaScript maliciosa en el menú de la campaña y activar payload cuando la campaña se elimine del menú.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amdkfd: Reparar advertencia de dependencia de bloqueo =============================== ======================== ADVERTENCIA: posible dependencia de bloqueo circular detectada 6.5.0-kfd-fkuehlin #276 No contaminado -------- ---------------------------------------------- ktrabajador/8: 2/2676 está intentando adquirir el bloqueo: ffff9435aae95c88 ((work_completion)(&svm_bo->eviction_work)){+.+.}-{0:0}, en: __flush_work+0x52/0x550 pero la tarea ya mantiene el bloqueo: ffff9435cd8e1720 ( &svms->lock){+.+.}-{3:3}, en: svm_range_deferred_list_work+0xe8/0x340 [amdgpu] cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #2 (&svms->lock){+.+.}-{3:3}: __mutex_lock+0x97/0xd30 kfd_ioctl_alloc_memory_of_gpu+0x6d/0x3c0 [amdgpu] kfd_ioctl+0x1b2 /0x5d0 [amdgpu] __x64_sys_ioctl+0x86/0xc0 do_syscall_64+0x39/0x80 Entry_SYSCALL_64_after_hwframe+0x63/0xcd -> #1 (&mm->mmap_lock){++++}-{3:3}: down_read+0x42/0x160 svm_range_evi ct_svm_bo_worker+ 0x8b/0x340 [amdgpu] proceso_one_work+0x27a/0x540 trabajador_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&svm_bo->eviction_work) ){+.+ .}-{0:0}: __lock_acquire+0x1426/0x2200 lock_acquire+0xc1/0x2b0 __flush_work+0x80/0x550 __cancel_work_timer+0x109/0x190 svm_range_bo_release+0xdc/0x1c0 [amdgpu] svm_range_free+0x175 /0x180 [amdgpu] svm_range_deferred_list_work+0x15d/0x340 [amdgpu] Process_one_work+0x27a/0x540 trabajador_thread+0x53/0x3e0 kthread+0xeb/0x120 ret_from_fork+0x31/0x50 ret_from_fork_asm+0x11/0x20 otra información que podría ayudarnos a depurar esto: Existe cadena de: (work_completion)(&svm_bo->eviction_work) --> &mm->mmap_lock --> &svms->lock Posible escenario de bloqueo inseguro: CPU0 CPU1 ---- ---- lock(&svms->lock); bloquear(&mm->mmap_lock); bloquear(&svms->bloquear); lock((work_completion)(&svm_bo->eviction_work)); Creo que esto realmente no puede llevar a un punto muerto en la práctica, porque svm_range_evict_svm_bo_worker solo toma mmap_read_lock si el recuento de BO no es 0. Eso significa que es imposible que svm_range_bo_release se esté ejecutando al mismo tiempo. Sin embargo, no existe una buena forma de anotar esto. Para evitar el problema, tome una referencia de BO en svm_range_schedule_evict_svm_bo en lugar de en el trabajador. De esa manera, es imposible que un BO sea liberado mientras el trabajo de desalojo está pendiente y la llamada cancel_work_sync en svm_range_bo_release puede eliminarse. v2: Use svm_bo_ref_unless_zero y explicó por qué es seguro. También se eliminaron las comprobaciones redundantes que ya se realizan en amdkfd_fence_enable_signaling.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pds_core: evita problemas de ejecución relacionados con adminq. Hay varias rutas que pueden resultar en el uso de adminq de pdsc. [1] pdsc_adminq_isr y el trabajo resultante de queue_work(), es decir, pdsc_work_thread()->pdsc_process_adminq() [2] pdsc_adminq_post() Cuando el dispositivo se reinicia mediante reinicio de PCIe y/o un ciclo fw_down/fw_up debido a un estado incorrecto de PCIe o mal estado del dispositivo, adminq se destruye y se vuelve a crear. Puede ocurrir una desreferencia de puntero NULL si [1] o [2] ocurre después de que adminq ya esté destruido. Para solucionar este problema, agregue algunas comprobaciones de estado adicionales e implemente el recuento de referencias para usos de adminq. Se utilizó el recuento de referencias porque varios subprocesos pueden intentar acceder a adminq al mismo tiempo a través de [1] o [2]. Además, varios clientes (es decir, pds-vfio-pci) pueden utilizar [2] al mismo tiempo. adminq_refcnt se inicializa en 1 cuando adminq se ha asignado y está listo para usar. Los usuarios/clientes de adminq (es decir, [1] y [2]) incrementarán el refcnt cuando utilicen adminq. Cuando el controlador entra en un ciclo fw_down, establecerá el bit PDSC_S_FW_DEAD y luego esperará a que adminq_refcnt llegue a 1. Configurar PDSC_S_FW_DEAD antes de esperar evitará más incrementos de adminq_refcnt. Esperar a que adminq_refcnt llegue a 1 permite que cualquier usuario actual de adminq finalice antes de que el controlador libere adminq. Una vez que adminq_refcnt llega a 1, el controlador borra el refcnt para indicar que adminq se elimina y no se puede utilizar. En el ciclo fw_up, el controlador inicializará una vez más adminq_refcnt en 1, lo que permitirá utilizar adminq nuevamente.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: af_unix: corrige el bloqueo positivo en sk_diag_dump_icons() syzbot informó un bloqueo del bloqueo [1]. La confirmación culpada insinuó la posible violación de lockdep y el código usó unix_state_lock_nested() en un intento de silenciar lockdep. No es suficiente, porque unix_state_lock_nested() ya se usa desde unix_state_double_lock(). Necesitamos usar una subclase separada. Este parche agrega una enumeración distinta para hacer las cosas más explícitas. Utilice también swap() en unix_state_double_lock() como limpieza. v2: agregue una palabra clave en línea faltante a unix_state_lock_nested() [1] ADVERTENCIA: se detectó posible dependencia de bloqueo circular 6.8.0-rc1-syzkaller-00356-g8a696a29c690 #0 No contaminado syz-executor.1/2542 está intentando adquirir el bloqueo: ffff88808b5df9e8 (rlock-AF_UNIX){+.+.}-{2:2}, en: skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 pero la tarea ya mantiene el bloqueo: ffff88808b5dfe70 (&u->lock/1) {+.+.}-{2:2}, en: unix_dgram_sendmsg+0xfc7/0x2200 net/unix/af_unix.c:2089 cuyo bloqueo ya depende del nuevo bloqueo. la cadena de dependencia existente (en orden inverso) es: -> #1 (&u->lock/1){+.+.}-{2:2}: lock_acquire+0x1e3/0x530 kernel/locking/lockdep.c:5754 _raw_spin_lock_nested+0x31/0x40 kernel/locking/spinlock.c:378 sk_diag_dump_icons net/unix/diag.c:87 [en línea] sk_diag_fill+0x6ea/0xfe0 net/unix/diag.c:157 sk_diag_dump net/unix/diag.c: 196 [en línea] unix_diag_dump+0x3e9/0x630 net/unix/diag.c:220 netlink_dump+0x5c1/0xcd0 net/netlink/af_netlink.c:2264 __netlink_dump_start+0x5d7/0x780 net/netlink/af_netlink.c:2370 netlink_dump_start include/linux /netlink.h:338 [en línea] unix_diag_handler_dump+0x1c3/0x8f0 net/unix/diag.c:319 sock_diag_rcv_msg+0xe3/0x400 netlink_rcv_skb+0x1df/0x430 net/netlink/af_netlink.c:2543 sock_diag_rcv+0x2a/0x 40 neto/núcleo /sock_diag.c:280 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [en línea] netlink_unicast+0x7e6/0x980 net/netlink/af_netlink.c:1367 netlink_sendmsg+0xa37/0xd70 net/netlink/af_netlink.c:1908 sock_sendmsg_nosec net/ socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] sock_write_iter+0x39a/0x520 net/socket.c:1160 call_write_iter include/linux/fs.h:2085 [en línea] new_sync_write fs/read_write.c :497 [en línea] vfs_write+0xa74/0xca0 fs/read_write.c:590 ksys_write+0x1a0/0x2c0 fs/read_write.c:643 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xf5/0x230 arch /x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b -> #0 (rlock-AF_UNIX){+.+.}-{2:2}: check_prev_add kernel/locking/lockdep.c:3134 [en línea] check_prevs_add kernel/locking/lockdep.c:3253 [en línea] validar_chain+0x1909/0x5ab0 kernel/locking/lockdep.c:3869 __lock_acquire+0x1345/0x1fd0 kernel/locking/lockdep.c:5137 lock_acquire+0x1e3/0x530 kernel/locking/ lockdep.c:5754 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [en línea] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 skb_queue_tail+0x36/0x120 net/core/skbuff.c:3863 unix_dgram_send mensaje+0x15d9/ 0x2200 net/unix/af_unix.c:2112 sock_sendmsg_nosec net/socket.c:730 [en línea] __sock_sendmsg net/socket.c:745 [en línea] ____sys_sendmsg+0x592/0x890 net/socket.c:2584 ___sys_sendmsg net/socket.c :2638 [en línea] __sys_sendmmsg+0x3b2/0x730 net/socket.c:2724 __do_sys_sendmmsg net/socket.c:2753 [en línea] __se_sys_sendmmsg net/socket.c:2750 [en línea] __x64_sys_sendmmsg+0xa0/0xb0 net /socket.c: 2750 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf5/0x230 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b otra información que podría ayudarnos a depurar esto: Posible escenario de bloqueo inseguro : CPU0 ---truncado---