Vulnerabilidades

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: nodo de software: Se corrige una comprobación OOB en software_node_get_reference_args(). software_node_get_reference_args() busca obtener el elemento @index-ésimo, por lo que el valor de la propiedad requiere al menos '(index + 1) * sizeof(*ref)' bytes, pero esto no se puede garantizar con la comprobación OOB actual y puede causar OOB para una propiedad mal formada. Se corrige usando como comprobación OOB '((index + 1) * sizeof(*ref) > prop->length)'.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mt76: mt7996: la eliminación de fragmentos con RA de multidifusión o difusión. La fragmentación IEEE 802.11 solo se puede aplicar a tramas de unidifusión. Por lo tanto, se deben eliminar fragmentos con RA de multidifusión o difusión. Este parche corrige vulnerabilidades como CVE-2020-26145.

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: ftrace: Reparar UAF cuando se busca kallsym después de ftrace deshabilitado El siguiente problema ocurre con un módulo con errores: ERROR: no se puede controlar el error de página para la dirección: ffffffffc05d0218 PGD 1bd66f067 P4D 1bd66f067 PUD 1bd671067 PMD 101808067 PTE 0 Oops: Oops: 0000 [#1] SMP KASAN PTI Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS RIP: 0010:sized_strscpy+0x81/0x2f0 RSP: 0018:ffff88812d76fa08 EFLAGS: 00010246 RAX: 0000000000000000 RBX: fffffffc0601010 RCX: dffffc0000000000 RDX: 0000000000000038 RSI: dffffc0000000000 RDI: ffff88812608da2d RBP: 8080808080808080 R08: ffff88812608da2d R09: ffff88812608da68 R10: ffff88812608d82d R11: ffff88812608d810 R12: 000000000000038 R13: ffff88812608da2d R14: ffffffffc05d0218 R15: fefefefefefefeff FS: 00007fef552de740(0000) GS:ffff8884251c7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffc05d0218 CR3: 00000001146f0000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 00000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Rastreo de llamadas: ftrace_mod_get_kallsym+0x1ac/0x590 update_iter_mod+0x239/0x5b0 s_next+0x5b/0xa0 seq_read_iter+0x8c9/0x1070 seq_read+0x249/0x3b0 proc_reg_read+0x1b0/0x280 vfs_read+0x17f/0x920 ksys_read+0xf3/0x1c0 do_syscall_64+0x5f/0x2e0 entry_SYSCALL_64_after_hwframe+0x76/0x7e El problema anterior puede ocurrir de la siguiente manera: (1) Agregar punto de seguimiento de kprobe; (2) insmod test.ko; (3) El módulo activa ftrace deshabilitado; (4) rmmod test.ko; (5) cat /proc/kallsyms; --> Activará UAF como test.ko ya eliminado; ftrace_mod_get_kallsym() ... strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); ... El problema es cuando un módulo activa un problema con ftrace y establece ftrace_disable. ftrace_disable se establece cuando se descubre una anomalía y para evitar más daños, ftrace detiene toda modificación de texto. El problema que ocurrió fue que ftrace_disable detiene más que solo la modificación de texto. Cuando se carga un módulo, también se pueden rastrear sus funciones de inicio. Dado que kallsyms elimina las funciones de inicio después de cargar un módulo, ftrace las guarda cuando el módulo se carga y se habilita el seguimiento de funciones. Esto permite que la salida del seguimiento de funciones muestre los nombres de las funciones de inicio en lugar de solo sus direcciones de memoria. Al eliminar un módulo, se llama a ftrace_release_mod() y, si ftrace_disable está configurado, simplemente regresa sin hacer nada más. El problema es que deja la lista de mods (mod_list) aún activa, y si se llama a kallsyms, este ejecutará este código y accederá a la memoria del módulo ya liberada, ya que devolverá: strscpy(module_name, mod_map->mod->name, MODULE_NAME_LEN); Donde el "mod" ya no existe, lo que genera un error de UAF.

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.