Vulnerabilidades

Se ha detectado una vulnerabilidad clasificada como problemática en caipeichao ThinkOX 1.0. Esta afecta a una parte desconocida del archivo /ThinkOX-master/index.php?s=/Weibo/Index/search.html del componente Search. La manipulación de las palabras clave del argumento provoca ataques de cross site scripting. Es posible iniciar el ataque de forma remota. Se ha hecho público el exploit y puede que sea utilizado.

Se encontró una vulnerabilidad en SourceCodester Gym Management System 1.0. Se ha clasificado como crítica. Este problema afecta a una funcionalidad desconocida del archivo /signup.php. La manipulación del argumento `user_name` provoca una inyección SQL. El ataque puede ejecutarse remotamente. Se ha hecho público el exploit y puede que sea utilizado.

El complemento User Submitted Posts – Enable Users to Submit Posts from the Front End para WordPress es vulnerable a Cross-Site Scripting Almacenado a través de la configuración de administrador en todas las versiones hasta la 20240319 incluida, debido a una depuración de entrada y al escape de salida insuficiente. Esto permite a atacantes autenticados, con permisos de administrador o superiores, inyectar scripts web arbitrarios en páginas que se ejecutarán al acceder un usuario a una página inyectada. Esto solo afecta a instalaciones multisitio y a instalaciones donde se ha deshabilitado unfiltered_html.

Se encontró una vulnerabilidad en itning Student Homework Management System hasta la versión 1.2.7. Se ha clasificado como problemática. Se ve afectada una función desconocida del archivo /shw_war/fileupload del componente "Editar Página de Trabajo". La manipulación del argumento "Curso" provoca cross site scripting. Es posible ejecutar el ataque de forma remota. Se ha hecho público el exploit y puede que sea utilizado. Esta vulnerabilidad solo afecta a los productos que ya no reciben soporte del fabricante.

Se encontró una vulnerabilidad en itning Student Homework Management System hasta la versión 1.2.7. Se ha declarado problemática. Esta vulnerabilidad afecta a una funcionalidad desconocida. La manipulación provoca cross-site request forgery. El ataque puede ejecutarse remotamente. Se ha hecho público el exploit y puede que sea utilizado. Múltiples endpoints podrían verse afectados.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: Bluetooth: Corrección del código de error en chan_alloc_skb_cb(). La función chan_alloc_skb_cb() debe devolver indicadores de error en caso de error. Devolver NULL provocará una desreferencia a NULL.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: ethernet: ti: am65-cpsw: Se ha corregido la secuencia de registro de NAPI. Registrar las interrupciones para los canales DMA TX o RX antes de registrar sus respectivas devoluciones de llamada NAPI puede provocar una desreferencia de puntero nulo. En la práctica, esto se considera un evento aleatorio, ya que depende de la aleatoriedad asociada con la generación de tráfico por parte de Linux y la recepción de tráfico desde la red.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ipv6: Se corrigió la fuga de memoria de nhc_pcpu_rth_output en fib_check_nh_v6_gw(). fib_check_nh_v6_gw() espera que fib6_nh_init() limpie todo cuando falla. El commit 7dd73168e273 ("ipv6: Asignar siempre memoria pcpu en un fib6_nh") movió fib_nh_common_init() antes de alloc_percpu_gfp() dentro de fib6_nh_init(), pero olvidó añadir la limpieza para fib6_nh->nh_common.nhc_pcpu_rth_output en caso de que no se asigne fib6_nh->rt6i_pcpu, lo que resulta en una fuga de memoria. Invoquemos fib_nh_common_release() y borremos nhc_pcpu_rth_output en la ruta de error. Tenga en cuenta que podemos eliminar la llamada a fib6_nh_release() en nh_create_ipv6() más adelante en net-next.git.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/radeon: soluciona el problema de tamaño no inicializado en radeon_vce_cs_parse() En el improbable caso de que el flujo de comandos pasado desde el espacio de usuario a través de la llamada ioctl() a radeon_vce_cs_parse() esté manipulado de forma extraña y el primer comando a ejecutar sea codificar (caso 0x03000001), la función en cuestión intentará llamar a radeon_vce_cs_reloc() con el argumento de tamaño que no se ha inicializado correctamente. Específicamente, 'size' apuntará a la variable 'tmp' antes de que a esta última se le haya asignado algún valor. Vaya a lo seguro e inicialice 'tmp' con 0, lo que garantiza que radeon_vce_cs_reloc() detecte un error temprano en casos como estos. Encontrado por el Centro de Verificación de Linux (linuxtesting.org) con la herramienta de análisis estático SVACE. (seleccionado del commit 2d52de55f9ee7aaee0e09ac443f77855989c6b68)

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: proc: corrección de UAF en proc_get_inode(). Corrección de la competencia entre rmmod y la instanciación de inodo de /proc/XXX. El error es que pde->proc_ops no pertenece a /proc, sino a un módulo; por lo tanto, desreferenciarlo después de registrar la entrada /proc es un error, a menos que se haya usado el par use_pde/unuse_pde(). Se puede evitar usar_pde/unuse_pde (¡2 operaciones atómicas!) porque pde->proc_ops nunca cambia, de modo que la información necesaria para la instanciación de inodo se puede guardar _antes_ de proc_register() en el propio PDE y usarse más tarde, evitando la desreferencia de pde->proc_ops->... . rmmod lookup sys_delete_module proc_lookup_de pde_get(de); proc_get_inode(dir->i_sb, de); mod->exit() proc_remove eliminar_subárbol_proc proc_entry_rundown(de); liberar_módulo(mod); if (S_ISREG(inode->i_mode)) if (de->proc_ops->proc_read_iter) --> Como el módulo ya está liberado, se activará UAF ERROR: no se puede manejar el error de página para la dirección: fffffbfff80a702b PGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0 Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:proc_get_inode+0x302/0x6e0 RSP: 0018:ffff88811c837998 EFLAGS: 00010a06 RAX: dffffc0000000000 RBX: fffffffc0538140 RCX: 0000000000000007 RDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158 RBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20 R10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0 R13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001 FS: 00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0 DR0: 00000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: proc_lookup_de+0x11f/0x2e0 __lookup_slow+0x188/0x350 walk_component+0x2ab/0x4f0 path_lookupat+0x120/0x660 filename_lookup+0x1ce/0x560 vfs_statx+0xac/0x150 __do_sys_newstat+0x96/0x110 do_syscall_64+0x5f/0x170 entry_SYSCALL_64_after_hwframe+0x76/0x7e [adobriyan@gmail.com: no realice 2 operaciones atómicas en la ruta común]

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: atm: se corrige el use after free en lec_send() La operación ->send() libera skb, así que guarde la longitud antes de llamar a ->send() para evitar un use after free.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: can: ucan: fix out of bound read in strscpy() source Commit 7fdaf8966aae ("can: ucan: use strscpy() to instead of strncpy()") introdujo involuntariamente una lectura fuera de los límite de un byte en el argumento source de strscpy() (lo cual es un poco irónico sabiendo que strscpy() está destinado a ser una alternativa más segura :)). Consideremos los siguientes búferes: dest[len + 1]; /* terminará en NUL */ src[len]; /* puede que no termine en NUL */ Al hacer: strncpy(dest, src, len); dest[len] = '\0'; strncpy() leerá hasta len bytes desde src. Por otro lado: strscpy(dest, src, len + 1); Leerá hasta len + 1 bytes de src; es decir, se producirá una lectura fuera de los límites de un byte en src si no termina en NUL. Tenga en cuenta que el byte src[len] nunca se copia, pero strscpy() aún necesita leerlo para verificar si se produjo un truncamiento. Este mismo patrón ocurrió en ucan. La causa raíz es que el origen no termina en NUL. En lugar de hacer una copia en un búfer local, termine directamente en NUL tan pronto como usb_control_msg() regrese. Con esto, se puede eliminar la variable local firmware_str[]. Además, realice un par de refactorizaciones: - ucan_ctl_payload->raw solo se usa para la cadena de firmware, así que renómbrelo a ucan_ctl_payload->fw_str y cambie su tipo de u8 a char. - ucan_device_request_in() solo se utiliza para recuperar la cadena de firmware, así que cámbiele el nombre a ucan_get_fw_str() y refactorícelo para que gestione directamente toda la lógica de terminación de la cadena.