Vulnerabilidades

La interfaz web del Extensor WiFi WDR201A (HW V2.1, FW LFMZX28040922V1.02) contiene mecanismos de divulgación de credenciales codificados de forma rígida (en forma de Server Side Include) dentro de múltiples páginas web del lado del servidor, incluyendo login.shtml y settings.shtml. Estas páginas incrustan directivas de ejecución del lado del servidor que recuperan y exponen dinámicamente la contraseña de administración web de la memoria no volátil en tiempo de ejecución.

El Extensor WiFi WDR201A (HW V2.1, FW LFMZX28040922V1.02) implementa un mecanismo de autenticación defectuoso en su interfaz de gestión web. La página de inicio de sesión no aplica correctamente la validación de sesión, permitiendo a los atacantes eludir la autenticación accediendo directamente a puntos finales restringidos de la aplicación web mediante navegación forzada.

Existe una vulnerabilidad de inyección de comandos en la interfaz de gestión web del Extensor WiFi WDR201A (HW V2.1, FW LFMZX28040922V1.02). El endpoint adm.cgi sanitiza de forma inadecuada la entrada suministrada por el usuario proporcionada a un parámetro relacionado con comandos en la funcionalidad sysCMD.

Vulnerabilidad de desbordamiento de búfer en giflib v.5.2.2 permite a un atacante remoto causar una denegación de servicio a través de EGifGCBToExtension sobrescribiendo un bloque de extensión de control gráfico existente sin validar su tamaño asignado.

Dell Integrated Dell Remote Access Controller 9, versiones 14G anteriores a 7.00.00.181, versiones 15G y 16G anteriores a 7.20.10.50 y Dell Integrated Dell Remote Access Controller 10, versiones 17G anteriores a 1.20.25.00, contienen una vulnerabilidad de control de procesos. Un atacante con altos privilegios con acceso a la red adyacente podría potencialmente explotar esta vulnerabilidad, lo que llevaría a la ejecución de código.

Dell Integrated Dell Remote Access Controller 9, versiones 14G anteriores a 7.00.00.174, versiones 15G y 16G anteriores a 7.10.90.00, contienen una vulnerabilidad de Exposición de Información Sensible del Sistema Debido a Información de Depuración No Borrada. Un atacante con altos privilegios y acceso remoto podría potencialmente explotar esta vulnerabilidad, lo que llevaría a la revelación de información.

nghttp2 es una implementación del Protocolo de Transferencia de Hipertexto versión 2 en C. Antes de la versión 1.68.1, la biblioteca nghttp2 deja de leer los datos entrantes cuando la aplicación llama a la API pública orientada al usuario 'nghttp2_session_terminate_session' o 'nghttp2_session_terminate_session2'. Estas pueden ser llamadas internamente por la biblioteca cuando esta detecta una situación sujeta a error de conexión. Debido a la falta de validación del estado interno, la biblioteca sigue leyendo el resto de los datos después de que se llama a una de esas APIs. Luego, recibir una trama malformada que causa FRAME_SIZE_ERROR provoca un fallo de aserción. nghttp2 v1.68.1 añade la validación de estado faltante para evitar el fallo de aserción. No se conocen soluciones alternativas disponibles.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: Solo permitir que act_ct se vincule a qdiscs clsact/de entrada y bloques compartidos<br /> <br /> Como Paolo dijo anteriormente [1]:<br /> <br /> &amp;#39;Desde el commit culpado a continuación, classify puede devolver TC_ACT_CONSUMED mientras el skb actual está siendo retenido por el motor de desfragmentación. Según lo informado por GangMin Kim, si dicho paquete es uno que puede causar un UaF cuando el motor de desfragmentación más tarde intente tocar de nuevo dicho paquete.&amp;#39;<br /> <br /> act_ct nunca estuvo destinado a ser usado en la ruta de salida, sin embargo, algunos usuarios lo están adjuntando a la salida hoy [2]. Intentando llegar a un punto intermedio, notamos que, mientras que la mayoría de los qdiscs no están manejando TC_ACT_CONSUMED, los qdiscs clsact/de entrada sí lo están. Con eso en mente, abordamos el problema permitiendo solo que act_ct se vincule a qdiscs clsact/de entrada y bloques compartidos. De esa manera, todavía es posible adjuntar act_ct a la salida (aunque solo con clsact).<br /> <br /> [1] https://lore.kernel.org/netdev/674b8cbfc385c6f37fb29a1de08d8fe5c2b0fbee.1771321118.git.pabeni@redhat.com/<br /> [2] https://lore.kernel.org/netdev/cc6bfb4a-4a2b-42d8-b9ce-7ef6644fb22b@ovn.org/

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> Revertir &amp;#39;drm/amd: Comprobar si ASPM está habilitado desde el subsistema PCIe&amp;#39;<br /> <br /> Esto revierte el commit 7294863a6f01248d72b61d38478978d638641bee.<br /> <br /> Este commit fue aplicado erróneamente de nuevo después del commit 0ab5d711ec74<br /> (&amp;#39;drm/amd: Refactorizar amdgpu_aspm para ser evaluado por dispositivo&amp;#39;)<br /> lo eliminó, lo que llevó a fallos muy difíciles de depurar, cuando se usaba con un sistema con dos GPU AMD de las cuales solo una soporta ASPM.<br /> <br /> (seleccionado de forma selectiva del commit 97a9689300eb2b393ba5efc17c8e5db835917080)

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> f2fs: corrección para realizar una comprobación de coherencia en el pie de página del nodo en {read,write}_end_io<br /> <br /> -----------[ cut here ]------------<br /> BUG del kernel en fs/f2fs/data.c:358!<br /> Traza de llamadas:<br /> <br /> blk_update_request+0x5eb/0xe70 block/blk-mq.c:987<br /> blk_mq_end_request+0x3e/0x70 block/blk-mq.c:1149<br /> blk_complete_reqs block/blk-mq.c:1224 [inline]<br /> blk_done_softirq+0x107/0x160 block/blk-mq.c:1229<br /> handle_softirqs+0x283/0x870 kernel/softirq.c:579<br /> __do_softirq kernel/softirq.c:613 [inline]<br /> invoke_softirq kernel/softirq.c:453 [inline]<br /> __irq_exit_rcu+0xca/0x1f0 kernel/softirq.c:680<br /> irq_exit_rcu+0x9/0x30 kernel/softirq.c:696<br /> instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1050 [inline]<br /> sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1050<br /> <br /> <br /> En f2fs_write_end_io(), se detecta una inconsistencia entre el índice de la página de nodo (nid) y footer.nid de la página de nodo.<br /> <br /> Si el pie de página de la página de nodo está corrupto en una imagen sometida a fuzzing, entonces cargamos la página de nodo corrupta con un método asíncrono, p. ej., f2fs_ra_node_pages() o f2fs_ra_node_page(), donde no realizaremos una comprobación de coherencia en el pie de página del nodo; una vez que la página de nodo se vuelve sucia, encontraremos este error después de la escritura de vuelta de la página de nodo.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> fbdev: rivafb: corrige error de división en nv3_arb()<br /> <br /> Un programa de espacio de usuario puede activar el código de arbitraje RIVA NV3 llamando al ioctl FBIOPUT_VSCREENINFO en /dev/fb*. Al hacerlo, el controlador recalcula los parámetros de arbitraje FIFO en nv3_arb(), usando state-&amp;gt;mclk_khz (derivado del PRAMDAC MCLK PLL) como divisor sin validarlo primero.<br /> <br /> En una configuración normal, state-&amp;gt;mclk_khz es proporcionado por el hardware real y no es cero. Sin embargo, un atacante puede construir un dispositivo malicioso o mal configurado (p. ej., un dispositivo PCI manipulado/emulado) que expone una configuración PLL falsa, haciendo que state-&amp;gt;mclk_khz se vuelva cero. Una vez que nv3_get_param() llama a nv3_arb(), la división por state-&amp;gt;mclk_khz en el cálculo de gns causa un error de división y bloquea el kernel.<br /> <br /> Solucione esto verificando si state-&amp;gt;mclk_khz es cero y saliendo antes de realizar la división.<br /> <br /> El siguiente registro lo revela:<br /> <br /> rivafb: estableciendo la resolución Y virtual a 2184<br /> error de división: 0000 [#1] PREEMPT SMP KASAN PTI<br /> CPU: 0 PID: 2187 Comm: syz-executor.0 No contaminado 5.18.0-rc1+ #1<br /> Nombre del hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:nv3_arb drivers/video/fbdev/riva/riva_hw.c:439 [inline]<br /> RIP: 0010:nv3_get_param+0x3ab/0x13b0 drivers/video/fbdev/riva/riva_hw.c:546<br /> Traza de llamada:<br /> nv3CalcArbitration.constprop.0+0x255/0x460 drivers/video/fbdev/riva/riva_hw.c:603<br /> nv3UpdateArbitrationSettings drivers/video/fbdev/riva/riva_hw.c:637 [inline]<br /> CalcStateExt+0x447/0x1b90 drivers/video/fbdev/riva/riva_hw.c:1246<br /> riva_load_video_mode+0x8a9/0xea0 drivers/video/fbdev/riva/fbdev.c:779<br /> rivafb_set_par+0xc0/0x5f0 drivers/video/fbdev/riva/fbdev.c:1196<br /> fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1033<br /> do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1109<br /> fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1188<br /> __x64_sys_ioctl+0x122/0x190 fs/ioctl.c:856

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> f2fs: corrige el problema de inconsistencia del flag IS_CHECKPOINTED causado por escrituras concurrentes de commit atómico y checkpoint<br /> <br /> Durante las pruebas SPO, al montar F2FS, se devolvió un error -EINVAL desde<br /> f2fs_recover_inode_page. El problema ocurrió bajo el siguiente escenario<br /> <br /> Hilo A Hilo B<br /> f2fs_ioc_commit_atomic_write<br /> - f2fs_do_sync_file // atómico = true<br /> - f2fs_fsync_node_pages<br /> : last_folio = inode folio<br /> : schedule before folio_lock(last_folio) f2fs_write_checkpoint<br /> - block_operations// writeback last_folio<br /> - schedule before f2fs_flush_nat_entries<br /> : set_fsync_mark(last_folio, 1)<br /> : set_dentry_mark(last_folio, 1)<br /> : folio_mark_dirty(last_folio)<br /> - __write_node_folio(last_folio)<br /> : f2fs_down_read(&amp;amp;sbi-&amp;gt;node_write)//bloquea<br /> - f2fs_flush_nat_entries<br /> : {struct nat_entry}-&amp;gt;flag |= BIT(IS_CHECKPOINTED)<br /> - unblock_operations<br /> : f2fs_up_write(&amp;amp;sbi-&amp;gt;node_write)<br /> f2fs_write_checkpoint//retorna<br /> : f2fs_do_write_node_page()<br /> f2fs_ioc_commit_atomic_write//retorna<br /> SPO<br /> <br /> El Hilo A llama a f2fs_need_dentry_mark(sbi, ino), y el last_folio ya ha<br /> sido escrito una vez. Sin embargo, el {struct nat_entry}-&amp;gt;flag no tenía<br /> el IS_CHECKPOINTED establecido, causando que set_dentry_mark(last_folio, 1) y<br /> se escriba last_folio de nuevo después de que el Hilo B termine f2fs_write_checkpoint.<br /> <br /> Después de SPO y el reinicio, se detectó que {struct node_info}-&amp;gt;blk_addr<br /> no era NULL_ADDR porque el Hilo B escribió exitosamente el checkpoint.<br /> <br /> Este problema solo ocurre en escenarios de escritura atómica. Para operaciones<br /> fsync de archivos regulares, el folio debe estar sucio. Si<br /> block_operations-&amp;gt;f2fs_sync_node_pages envía exitosamente la escritura del folio,<br /> esta ruta no se ejecutará. De lo contrario, f2fs_write_checkpoint deberá esperar<br /> a que se complete el envío de la escritura del folio, ya que<br /> sbi-&amp;gt;nr_pages[F2FS_DIRTY_NODES] &amp;gt; 0. Por lo tanto, la situación en la que<br /> f2fs_need_dentry_mark verifica que el {struct nat_entry}-&amp;gt;flag sin el flag<br /> IS_CHECKPOINTED, pero la escritura del folio ya ha sido enviada, no ocurrirá.<br /> <br /> Por lo tanto, para fsync de archivos atómicos, sbi-&amp;gt;node_write debe adquirirse<br /> a través de __write_node_folio para asegurar que el flag IS_CHECKPOINTED<br /> indique correctamente que la escritura del checkpoint ha sido completada.