Vulnerabilidades

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.

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.

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 13.3 hasta la 17.11.6, la 18.0 hasta la 18.0.4 y la 18.1 hasta la 18.1.2 que podría haber permitido a los propietarios de proyectos autenticados eludir las restricciones de bifurcación a nivel de grupo manipulando las solicitudes de API.

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.

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: wifi: p54: evitar desbordamiento de búfer en p54_rx_eeprom_readback() Robert Morris informó: |Si un dispositivo USB malicioso se hace pasar por una interfaz wifi p54 de Intersil y genera un mensaje eeprom_readback con un eeprom->v1.len largo, p54_rx_eeprom_readback() copiará los datos del mensaje más allá del final de priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct p54_hdr *) skb->data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...] El controlador establece eeprom->v{1,2}.len en p54_download_eeprom(). Se supone que el dispositivo debe proporcionar la misma longitud al controlador. Sin embargo, es posible (como se muestra en el informe) modificar el valor para que provoque un bloqueo o pánico debido a un desbordamiento. Este parche soluciona el problema añadiendo el tamaño al contexto común del dispositivo, de modo que p54_rx_eeprom_readback ya no depende de valores posiblemente manipulados. Dicho esto, también comprueba si el firmware alteró el valor y ya no los copia. La única pequeña ventaja es que, antes de que el controlador intente leer la EEPROM, necesita cargar un firmware. El firmware del proveedor tiene una licencia propietaria y, por ello, no está presente en la mayoría de las distribuciones por defecto.

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.