Vulnerabilidades

Un archivo RFA manipulado con fines maliciosos, al analizarse mediante Autodesk Revit, puede generar una vulnerabilidad de corrupción de memoria. Un agente malicioso puede aprovechar esta vulnerabilidad para ejecutar código arbitrario en el contexto del proceso actual.

Un archivo RTE manipulado con fines maliciosos, al analizarse mediante Autodesk Revit, puede generar una vulnerabilidad de desbordamiento basado en montón. Un agente malicioso puede aprovechar esta vulnerabilidad para provocar un bloqueo, leer datos confidenciales o ejecutar código arbitrario en el contexto del proceso actual.

Se detectó una falla de desbordamiento de búfer de pila (desviación de uno) en el software GnuTLS, en la lógica de análisis de plantillas de la utilidad certtool. Al leer ciertas configuraciones de un archivo de plantilla, permite a un atacante provocar una escritura fuera de los límites (OOB) en un puntero nulo, lo que resulta en corrupción de memoria y una denegación de servicio (DoS) que podría bloquear el sistema.

La vulnerabilidad de control inadecuado de la generación de código ('Inyección de código') en OpenText™ Directory Services permite la inclusión remota de código. Esta vulnerabilidad podría permitir el acceso al sistema mediante la inyección de scripts. Este problema afecta a los Servicios de Directorio: 23.4.

Se ha descubierto un problema en GitLab EE que afecta a todas las versiones desde la 18.0 anterior a la 18.0.4 y desde la 18.1 anterior a la 18.1.2 que podría haber permitido a usuarios autenticados con privilegios de invitación eludir las restricciones de invitación de usuarios a nivel de grupo manipulando la funcionalidad de invitación de grupo.

La vulnerabilidad de requisitos de contraseña débiles en el monitor del sistema fotovoltaico “EcoGuideTAB” de Mitsubishi Electric Corporation (PV-DR004J y PV-DR004JA en todas sus versiones) permite a un atacante, dentro del rango de comunicación Wi-Fi entre las unidades del producto (unidad de medición y unidad de visualización), obtener la contraseña del SSID. Sin embargo, el producto no se ve afectado por esta vulnerabilidad si permanece sin uso durante un periodo determinado (predeterminado: 5 minutos) y entra en modo de ahorro de energía con la pantalla LCD apagada. Los productos afectados se discontinuaron en 2015 y el soporte técnico finalizó en 2020.

La vulnerabilidad de uso de credenciales codificadas en el monitor del sistema fotovoltaico “EcoGuideTAB” de Mitsubishi Electric Corporation (PV-DR004J y PV-DR004JA en todas sus versiones) permite a un atacante dentro del rango de comunicación Wi-Fi entre las unidades del producto (unidad de medición y unidad de visualización) divulgar información, como la energía generada y la electricidad vendida a la red eléctrica, almacenada en el producto, manipular o destruir información almacenada o configurada en el producto, o provocar una denegación de servicio (DoS) en el producto mediante el uso de un ID de usuario y una contraseña codificados, comunes a la serie del producto, obtenidos mediante la explotación de CVE-2025-5022. Sin embargo, el producto no se ve afectado por esta vulnerabilidad si permanece sin uso durante un período determinado (predeterminado: 5 minutos) y entra en modo de ahorro de energía con la pantalla LCD de la unidad de visualización apagada. Los productos afectados se discontinuaron en 2015 y el soporte técnico finalizó en 2020.

Se ha descubierto un problema en GitLab EE que afecta a todas las versiones desde la 18.0 hasta la 18.0.4 y desde la 18.1 hasta la 18.1.2 que podría haber permitido a los mantenedores autenticados eludir las restricciones de invitación de usuarios a nivel de grupo mediante el envío de solicitudes de API manipuladas.

Se ha descubierto un problema en GitLab CE/EE que afecta a todas las versiones desde la 17.11 anterior a la 17.11.6, la 18.0 anterior a la 18.0.4 y la 18.1 anterior a la 18.1.2 que, en determinadas condiciones, podría haber permitido a un atacante exitoso ejecutar acciones en nombre de los usuarios inyectando contenido malicioso.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPICA: se corrigen las fugas de caché de ACPI parse y parseext. Confirmación de ACPICA 8829e70e1360c81e7a5a901b5d4f48330e021ea5. Soy Seunghun Han y trabajo para el Instituto de Investigación de Seguridad Nacional de Corea del Sur. He estado investigando sobre ACPI y he encontrado una fuga de caché en casos de aborto temprano de ACPI. El registro de arranque de la pérdida de caché ACPI es el siguiente: [0.352414] ACPI: _OSI(Dispositivo de módulo) añadido [0.353182] ACPI: _OSI(Dispositivo de procesador) añadido [0.353182] ACPI: _OSI(Extensiones 3.0 _SCP) añadido [0.353182] ACPI: _OSI(Dispositivo agregador de procesador) añadido [0.356028] ACPI: No se puede iniciar el intérprete ACPI [0.356799] Error ACPI: No se pudo eliminar el controlador SCI (20170303/evmisc-281) [0.360215] kmem_cache_destroy Estado Acpi: La caché Slab todavía tiene objetos [0.360648] CPU: 0 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #10 [ 0.361273] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.361873] Rastreo de llamadas: [ 0.362243] ? dump_stack+0x5c/0x81 [ 0.362591] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.362944] ? acpi_sleep_proc_init+0x27/0x27 [ 0.363296] ? acpi_os_delete_cache+0xa/0x10 [ 0.363646] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.364000] ? acpi_terminate+0xa/0x14 [ 0.364000] ? acpi_init+0x2af/0x34f [ 0.364000] ? __class_create+0x4c/0x80 [ 0.364000] ? video_setup+0x7f/0x7f [ 0.364000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.364000] ? do_one_initcall+0x4e/0x1a0 [ 0.364000] ? kernel_init_freeable+0x189/0x20a [ 0.364000] ? rest_init+0xc0/0xc0 [ 0.364000] ? kernel_init+0xa/0x100 [ 0.364000] ? ret_from_fork+0x25/0x30 Analicé esta fuga de memoria en detalle. Descubrí que las cachés "Acpi-State" y "Acpi-Parse" se fusionaron porque el tamaño de los objetos de la caché era el mismo que el de la caché slab. Finalmente, descubrí que las cachés "Acpi-Parse" y "Acpi-parse_ext" se filtraron mediante el indicador SLAB_NEVER_MERGE de la función kmem_cache_create(). El punto de fuga de caché ACPI real es el siguiente: [0.360101] ACPI: _OSI(Dispositivo de módulo) añadido [0.360101] ACPI: _OSI(Dispositivo de procesador) añadido [0.360101] ACPI: _OSI(Extensiones 3.0 _SCP) añadido [0.361043] ACPI: _OSI(Dispositivo agregador de procesador) añadido [0.364016] ACPI: No se puede iniciar el intérprete ACPI [0.365061] Error ACPI: No se pudo eliminar el controlador SCI (20170303/evmisc-281) [0.368174] kmem_cache_destroy Acpi-Parse: La caché Slab aún tiene objetos [0.369332] CPU: 1 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #8 [ 0.371256] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.372000] Rastreo de llamadas: [ 0.372000] ? dump_stack+0x5c/0x81 [ 0.372000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.372000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.372000] ? acpi_os_delete_cache+0xa/0x10 [ 0.372000] ? acpi_ut_delete_caches+0x56/0x7b [0.372000] ? acpi_terminate+0xa/0x14 [0.372000] ? acpi_init+0x2af/0x34f [0.372000] ? __class_create+0x4c/0x80 [0.372000] ? video_setup+0x7f/0x7f [0.372000] ? acpi_sleep_proc_init+0x27/0x27 [0.372000] ? do_one_initcall+0x4e/0x1a0 [0.372000] ? kernel_init_freeable+0x189/0x20a [0.372000] ? rest_init+0xc0/0xc0 [ 0.372000] ? kernel_init+0xa/0x100 [ 0.372000] ? ret_from_fork+0x25/0x30 [ 0.388039] kmem_cache_destroy Acpi-parse_ext: La caché Slab aún tiene objetos [ 0.389063] CPU: 1 PID: 1 Comm: swapper/0 Contaminado: GW 4.12.0-rc4-next-20170608+ #8 [ 0.390557] Nombre del hardware: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 [ 0.392000] Rastreo de llamadas: [ 0.392000] ? dump_stack+0x5c/0x81 [ 0.392000] ? kmem_cache_destroy+0x1aa/0x1c0 [ 0.392000] ? acpi_sleep_proc_init+0x27/0x27 [ 0.392000] ? acpi_os_delete_cache+0xa/0x10 [ 0.392000] ? acpi_ut_delete_caches+0x6d/0x7b [ 0.392000] ? acpi_terminate+0xa/0x14 [ 0.392000] ? acpi_init+0x2af/0x3 ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: ACPICA: corrección de fuga de caché de operandos de ACPI en dswstate.c, confirmación de ACPICA 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732. Se detectó una fuga de caché de ACPI en el caso de terminación anticipada de ACPI y continuación del arranque. Cuando se produce una terminación anticipada debido a una tabla ACPI maliciosa, el kernel de Linux finaliza la función ACPI y continúa el proceso de arranque. Mientras el kernel finaliza la función ACPI, kmem_cache_destroy() informa de una fuga de caché de operandos de ACPI. El registro de arranque de la fuga de caché de operandos de ACPI es el siguiente: >[ 0.585957] ACPI: Added _OSI(Module Device) >[ 0.587218] ACPI: Added _OSI(Processor Device) >[ 0.588530] ACPI: Added _OSI(3.0 _SCP Extensions) >[ 0.589790] ACPI: Added _OSI(Processor Aggregator Device) >[ 0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155) >[ 0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88) >[ 0.597858] ACPI: Unable to start the ACPI Interpreter >[ 0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281) >[ 0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects >[ 0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26 >[ 0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006 >[ 0.609177] Call Trace: >[ 0.610063] ? dump_stack+0x5c/0x81 >[ 0.611118] ? kmem_cache_destroy+0x1aa/0x1c0 >[ 0.612632] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.613906] ? acpi_os_delete_cache+0xa/0x10 >[ 0.617986] ? acpi_ut_delete_caches+0x3f/0x7b >[ 0.619293] ? acpi_terminate+0xa/0x14 >[ 0.620394] ? acpi_init+0x2af/0x34f >[ 0.621616] ? __class_create+0x4c/0x80 >[ 0.623412] ? video_setup+0x7f/0x7f >[ 0.624585] ? acpi_sleep_proc_init+0x27/0x27 >[ 0.625861] ? do_one_initcall+0x4e/0x1a0 >[ 0.627513] ? kernel_init_freeable+0x19e/0x21f >[ 0.628972] ? rest_init+0x80/0x80 >[ 0.630043] ? kernel_init+0xa/0x100 >[ 0.631084] ? ret_from_fork+0x25/0x30 >[ 0.633343] vgaarb: loaded >[ 0.635036] EDAC MC: Ver: 3.0.0 >[ 0.638601] PCI: Probing PCI hardware >[ 0.639833] PCI host bridge to bus 0000:00 >[ 0.641031] pci_bus 0000:00: root bus resource [io 0x0000-0xffff] > ... Continuar con el arranque y se omite el registro ... Analicé esta pérdida de memoria en detalle y encontré que la función acpi_ds_obj_stack_pop_and_delete() calculó mal la parte superior de la pila. La función acpi_ds_obj_stack_push() usa walk_state->operand_index para la posición inicial del top, pero la función acpi_ds_obj_stack_pop_and_delete() considera el índice 0. Por lo tanto, esto provoca una fuga de memoria de operandos de ACPI. Esta fuga de caché representa una amenaza para la seguridad, ya que un kernel antiguo (<= 4.9) muestra las ubicaciones de memoria de las funciones del kernel en el volcado de pila. Algunos usuarios maliciosos podrían usar esta información para neutralizar la ASLR del kernel. Creé un parche para corregir la fuga de caché de operandos de ACPI.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para realizar comprobaciones de integridad en ino y xnid. syzbot reportó un error de f2fs como el siguiente: INFORMACIÓN: La tarea syz-executor140:5308 se bloqueó durante más de 143 segundos. No contaminada. 6.14.0-rc7-syzkaller-00069-g81e4f8d68c66 #0 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:syz-executor140 estado:D pila:24016 pid:5308 tgid:5308 ppid:5306 indicadores_de_tarea:0x400140 indicadores:0x00000006 Rastreo de llamadas: context_switch kernel/sched/core.c:5378 [inline] __schedule+0x190e/0x4c90 kernel/sched/core.c:6765 __schedule_loop kernel/sched/core.c:6842 [inline] schedule+0x14b/0x320 kernel/sched/core.c:6857 io_schedule+0x8d/0x110 kernel/sched/core.c:7690 folio_wait_bit_common+0x839/0xee0 mm/filemap.c:1317 __folio_lock mm/filemap.c:1664 [inline] folio_lock include/linux/pagemap.h:1163 [inline] __filemap_get_folio+0x147/0xb40 mm/filemap.c:1917 pagecache_get_page+0x2c/0x130 mm/folio-compat.c:87 find_get_page_flags include/linux/pagemap.h:842 [inline] f2fs_grab_cache_page+0x2b/0x320 fs/f2fs/f2fs.h:2776 __get_node_page+0x131/0x11b0 fs/f2fs/node.c:1463 read_xattr_block+0xfb/0x190 fs/f2fs/xattr.c:306 lookup_all_xattrs fs/f2fs/xattr.c:355 [inline] f2fs_getxattr+0x676/0xf70 fs/f2fs/xattr.c:533 __f2fs_get_acl+0x52/0x870 fs/f2fs/acl.c:179 f2fs_acl_create fs/f2fs/acl.c:375 [inline] f2fs_init_acl+0xd7/0x9b0 fs/f2fs/acl.c:418 f2fs_init_inode_metadata+0xa0f/0x1050 fs/f2fs/dir.c:539 f2fs_add_inline_entry+0x448/0x860 fs/f2fs/inline.c:666 f2fs_add_dentry+0xba/0x1e0 fs/f2fs/dir.c:765 f2fs_do_add_link+0x28c/0x3a0 fs/f2fs/dir.c:808 f2fs_add_link fs/f2fs/f2fs.h:3616 [inline] f2fs_mknod+0x2e8/0x5b0 fs/f2fs/namei.c:766 vfs_mknod+0x36d/0x3b0 fs/namei.c:4191 unix_bind_bsd net/unix/af_unix.c:1286 [inline] unix_bind+0x563/0xe30 net/unix/af_unix.c:1379 __sys_bind_socket net/socket.c:1817 [inline] __sys_bind+0x1e4/0x290 net/socket.c:1848 __do_sys_bind net/socket.c:1853 [inline] __se_sys_bind net/socket.c:1851 [inline] __x64_sys_bind+0x7a/0x90 net/socket.c:1851 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Volcamos y verificamos los metadatos del inodo dañado, muestra que su xattr_nid es el mismo que su i_ino. dump.f2fs -i 3 chaseyu.img.raw i_xattr_nid [0x 3 : 3] Entonces, durante mknod en el directorio dañado, intenta obtener y bloquear la página del inodo dos veces, lo que da como resultado un bloqueo. - f2fs_mknod - f2fs_add_inline_entry - f2fs_get_inode_page --- bloquear la página de inodo del directorio - f2fs_init_acl - f2fs_acl_create(dir,..) - __f2fs_get_acl - f2fs_getxattr - lookup_all_xattrs - __get_node_page --- intentar bloquear la página de inodo del directorio Para solucionar esto, agreguemos una verificación de cordura en ino y xnid.