Vulnerabilidades

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

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.

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.

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

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 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---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: llc: llame a sock_orphan() en el momento del lanzamiento syzbot informó un rastro interesante [1] causado por un puntero sk->sk_wq obsoleto en un socket llc cerrado. En El commit ff7b11aa481f ("net: socket: set sock->sk to NULL after call proto_ops::release()") Eric Biggers insinuó que a algunos protocolos les falta un sock_orphan(), necesitamos realizar una auditoría completa. En net-next, planeo borrar sock->sk de sock_orphan() y modificar el parche de Eric para agregar una advertencia. [1] ERROR: KASAN: slab-use-after-free en list_empty include/linux/list.h:373 [en línea] ERROR: KASAN: slab-use-after-free en waitqueue_active include/linux/wait.h:127 [en línea] ERROR: KASAN: slab-use-after-free en sock_def_write_space_wfree net/core/sock.c:3384 [en línea] ERROR: KASAN: slab-use-after-free en sock_wfree+0x9a8/0x9d0 net/core/sock .c:2468 Lectura del tamaño 8 en la dirección ffff88802f4fc880 por tarea ksoftirqd/1/27 CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0 Nombre de hardware: PC estándar QEMU (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 01/04/2014 Seguimiento de llamadas: __dump_stack lib/dump_stack.c:88 [en línea] dump_stack_lvl+0xd9/0x1b0 lib/dump_stack .c:106 print_address_description mm/kasan/report.c:377 [en línea] print_report+0xc4/0x620 mm/kasan/report.c:488 kasan_report+0xda/0x110 mm/kasan/report.c:601 list_empty include/linux/ list.h:373 [en línea] waitqueue_active include/linux/wait.h:127 [en línea] sock_def_write_space_wfree net/core/sock.c:3384 [en línea] sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468 skb_release_head_state+ 0xa3/0x2b0 net/core/skbuff.c:1080 skb_release_all net/core/skbuff.c:1092 [en línea] napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404 e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/ intel/e1000/e1000_main.c:1970 e1000_clean_tx_irq controladores/net/ethernet/intel/e1000/e1000_main.c:3860 [en línea] e1000_clean+0x4a1/0x26e0 controladores/net/ethernet/intel/e1000/e1000_main.c:3801 __ napi_poll. constprop.0+0xb4/0x540 net/core/dev.c:6576 napi_poll net/core/dev.c:6645 [en línea] net_rx_action+0x956/0xe90 net/core/dev.c:6778 __do_softirq+0x21a/0x8de kernel/ softirq.c:553 run_ksoftirqd kernel/softirq.c:921 [en línea] run_ksoftirqd+0x31/0x60 kernel/softirq.c:913 smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164 kthread+0x2c6/0x3a0 kernel/kthread.c :388 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242 Asignado por tarea 5167: kasan_save_stack+0x33/0x50 mm/ kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:314 [en línea] __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340 kasan_slab_alloc incluir /linux/kasan.h:201 [en línea] slab_post_alloc_hook mm/slub.c:3813 [en línea] slab_alloc_node mm/slub.c:3860 [en línea] kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879 alloc_inode_sb include/linux/ fs.h:3019 [en línea] sock_alloc_inode+0x25/0x1c0 net/socket.c:308 alloc_inode+0x5d/0x220 fs/inode.c:260 new_inode_pseudo+0x16/0x80 fs/inode.c:1005 sock_alloc+0x40/0x270 net /socket.c:634 __sock_create+0xbc/0x800 net/socket.c:1535 sock_create net/socket.c:1622 [en línea] __sys_socket_create net/socket.c:1659 [en línea] __sys_socket+0x14c/0x260 net/socket.c :1706 __do_sys_socket net/socket.c:1720 [en línea] __se_sys_socket net/socket.c:1718 [en línea] __x64_sys_socket+0x72/0xb0 net/socket.c:1718 do_syscall_x64 arch/x86/entry/common.c:52 [en línea ] do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Liberado por la tarea 0: kasan_save_stack+0x33/0x50 mm/kasan/common.c:47 kasan_save_track+0x14/0x30 mm/kasan/ common.c:68 kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640 veneno_slab_object mm/kasan/common.c:241 [en línea] __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257 kasan_slab_free include/linux /kasan.h:184 [en línea] slab_free_hook mm/slub.c:2121 [en línea ---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ipmr: corrige el pánico del kernel al reenviar paquetes mcast El stacktrace fue: [86.305548] ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000092 [86.306815] #PF: acceso de lectura del supervisor en modo kernel [ 86.307717] #PF: error_code(0x0000) - página no presente [ 86.308624] PGD 0 P4D 0 [ 86.309091] Ups: 0000 [#1] PREEMPT SMP NOPTI [ 86.309883] CPU: 2 PID: 3139 Comm: pimd Contaminado: GU 6.8.0-6wind-knet #1 [ 86.311027] Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 01/04/2014 [ 86.312728] RIP: 0010:ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985) [86.313399] Código: f9 1f 0f 87 85 03 00 00 48 8d 04 5b 48 8d 04 83 49 8d 44 c 5 00 48 8b 40 70 48 39 c2 0f 84 d9 00 00 00 49 8b 46 58 48 83 e0 fe <80> b8 92 00 00 00 00 0f 84 55 ff ff 49 83 47 38 01 45 85 e4 0f [ 86.316565] RSP : 0018:ffffad21c0583ae0 EFLAGS: 00010246 [ 86.317497] RAX: 0000000000000000 RBX: 00000000000000000 RCX: 00000000000000000 [ 86.318596] RDX: ff ff9559cb46c000 RSI: 0000000000000000 RDI: 0000000000000000 [ 86.319627] RBP: ffffad21c0583b30 R08: 00000000000000000 R09: 00000000000000000 [ 86.320650] R10: 0000000000000000 R11 : 0000000000000000 R12: 00000000000000001 [ 86.321672] R13: ffff9559c093a000 R14: ffff9559cc00b800 R15: ffff9559c09c1d80 [ 86.322873] FS: 0 0007f85db661980(0000) GS:ffff955a79d00000(0000) knlGS:0000000000000000 [ 86.324291] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [86.325314] CR2: 0000000000000092 CR3: 000000002f13a000 CR4: 0000000000350ef0 [86.326589] Seguimiento de llamadas: [86.327036] [86.327434] ? show_regs (/build/work/knet/arch/x86/kernel/dumpstack.c:479) [86.328049]? __die (/build/work/knet/arch/x86/kernel/dumpstack.c:421 /build/work/knet/arch/x86/kernel/dumpstack.c:434) [86.328508] ? page_fault_oops (/build/work/knet/arch/x86/mm/fault.c:707) [86.329107]? do_user_addr_fault (/build/work/knet/arch/x86/mm/fault.c:1264) [86.329756]? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [86.330350]? __irq_work_queue_local (/build/work/knet/kernel/irq_work.c:111 (discriminador 1)) [86.331013]? exc_page_fault (/build/work/knet/./arch/x86/include/asm/paravirt.h:693 /build/work/knet/arch/x86/mm/fault.c:1515 /build/work/knet/arch /x86/mm/fault.c:1563) [86.331702]? asm_exc_page_fault (/build/work/knet/./arch/x86/include/asm/idtentry.h:570) [86.332468]? ip_mr_forward (/build/work/knet/net/ipv4/ipmr.c:1985) [86.333183]? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [ 86.333920] ipmr_mfc_add (/build/work/knet/./include/linux/rcupdate.h:782 /build/work/knet /net/ipv4/ipmr.c:1009 /build/work/knet/net/ipv4/ipmr.c:1273) [86.334583]? __pfx_ipmr_hash_cmp (/build/work/knet/net/ipv4/ipmr.c:363) [ 86.335357] ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470) [ 86.336135] ? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [86.336854]? ip_mroute_setsockopt (/build/work/knet/net/ipv4/ipmr.c:1470) [ 86.337679] do_ip_setsockopt (/build/work/knet/net/ipv4/ip_sockglue.c:944) [ 86.338408] ? __pfx_unix_stream_read_actor (/build/work/knet/net/unix/af_unix.c:2862) [86.339232]? srso_return_thunk (/build/work/knet/arch/x86/lib/retpoline.S:223) [86.339809]? aa_sk_perm (/build/work/knet/security/apparmor/include/cred.h:153 /build/work/knet/security/apparmor/net.c:181) [ 86.340342] ip_setsockopt (/build/work/knet/net /ipv4/ip_sockglue.c:1415) [86.340859] raw_setsockopt (/build/work/knet/net/ipv4/raw.c:836) [86.341408] ? security_socket_setsockopt (/build/work/knet/security/security.c:4561 (discriminador 13)) [ 86.342116] sock_common_setsockopt (/build/work/knet/net/core/sock.c:3716) [ 86.342747] do_sock_setsockopt (/build /work/knet/net/socket.c:2313) [ 86.343363] __sys_setsockopt (/build/work/knet/./include/linux/file.h:32 /build/work/kn ---truncado---

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.