Vulnerabilidades

LinkAce es un archivo alojado en el servidor para recopilar enlaces de sus sitios web favoritos. Antes de la versión 1.15.6, existía una vulnerabilidad de cross-site scripting (XSS) reflejado en LinkAce. Este problema se produce en el campo "URL" del módulo "Editar enlace", donde la entrada del usuario no se desinfecta ni codifica correctamente antes de reflejarse en la respuesta HTML. Esto permite a los atacantes inyectar y ejecutar JavaScript arbitrario en el contexto del navegador de la víctima, lo que puede provocar un posible secuestro de sesión, robo de datos y acciones no autorizadas. Esta vulnerabilidad se solucionó en la versión 1.15.6.

LinkAce es un archivo alojado en el servidor para recopilar enlaces de sus sitios web favoritos. Antes de la versión 1.15.6, existía una vulnerabilidad de carga de archivos en LinkAce. Este problema se produce en la función "Importar marcadores", donde se pueden cargar archivos HTML maliciosos que contienen payloads de JavaScript. Estos payloads se ejecutan cuando se accede a los enlaces cargados, lo que genera posibles escenarios de XSS reflejado o persistentes. Esta vulnerabilidad se solucionó en la versión 1.15.6.

changedetection.io es un servicio gratuito de código abierto de detección de cambios en páginas web, vigilancia de sitios web, monitorización de reabastecimiento y notificación. La validación incorrecta de la entrada en la aplicación puede permitir a los atacantes realizar ataques de lectura local de archivos (LFR) o de path traversal. Estas vulnerabilidades ocurren cuando la entrada del usuario se utiliza para construir rutas de archivos sin una desinfección o validación adecuadas. Por ejemplo, el uso de file:../../../etc/passwd o file: ///etc/passwd puede eludir validaciones débiles y permitir el acceso no autorizado a archivos confidenciales. Aunque esto se ha solucionado en un parche anterior, sigue siendo insuficiente. Esta vulnerabilidad se ha corregido en la versión 0.48.05.

Se ha encontrado una vulnerabilidad clasificada como crítica en DrayTek Vigor2960 y Vigor300B 1.5.1.4. Se trata de una función desconocida del archivo /cgi-bin/mainfunction.cgi/apmcfgupload del componente Web Management Interface. La manipulación del argumento session provoca la inyección de comandos del sistema operativo. Es posible lanzar el ataque de forma remota. El exploit se ha hecho público y puede utilizarse. La actualización a la versión 1.5.1.5 puede solucionar este problema. Se recomienda actualizar el componente afectado.

Los modelos del router Four-Faith F3x24 y F3x36 se ven afectados por una vulnerabilidad de inyección de comandos del sistema operativo (OS). Al menos la versión de firmware 2.0 permite a los atacantes autenticados y remotos ejecutar comandos arbitrarios del SO a través de HTTP al modificar la hora del sistema mediante apply.cgi. Además, esta versión de firmware tiene credenciales predeterminadas que, si no se modifican, convertirían efectivamente esta vulnerabilidad en un problema de ejecución de comandos del SO no autenticados y remotos.

Se ha encontrado una vulnerabilidad clasificada como crítica en DrayTek Vigor2960 y Vigor300B 1.5.1.3/1.5.1.4. Este problema afecta a algunos procesos desconocidos del archivo /cgi-bin/mainfunction.cgi/apmcfgupptim del componente Web Management Interface. La manipulación del argumento session lleva a la inyección de comandos del sistema operativo. El ataque puede iniciarse de forma remota. El exploit se ha hecho público y puede utilizarse. La actualización a la versión 1.5.1.5 puede solucionar este problema. Se recomienda actualizar el componente afectado.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: virtio_net: punto de invocación correcto de netdev_tx_reset_queue() Cuando virtnet_close es seguido por virtnet_open, es posible que algunas finalizaciones de TX permanezcan sin consumir, hasta que finalmente se procesen durante el primer sondeo NAPI después de netdev_tx_reset_queue(), lo que resulta en un bloqueo [1]. el commit b96ed2c97c79 ("virtio_net: mover la llamada netdev_tx_reset_queue() antes de la habilitación de napi RX") no fue suficiente para eliminar todos los casos de bloqueo de BQL para virtio-net. Este problema se puede reproducir con el último maestro net-next ejecutando: `while :; do ip l set DEV down; ip l set DEV up; done` bajo una carga de TX de red pesada desde el interior de la máquina. netdev_tx_reset_queue() en realidad se puede eliminar de la ruta virtnet_open; el dispositivo no se detiene en ningún caso. Para la parte principal de BQL, es como si el tráfico casi dejara de existir durante un período. Para el detector de bloqueo agregado a BQL, incluso si virtnet_close pudiera de alguna manera provocar que algunas finalizaciones de TX se retrasaran durante mucho tiempo, seguido de virtnet_open, podemos simplemente tomarlo como un bloqueo como se menciona en el commit 6025b9135f7a ("net: dqs: agregar detector de bloqueo de NIC basado en BQL"). Tenga en cuenta también que los usuarios aún pueden restablecer stall_max a través de sysfs. Por lo tanto, elimine netdev_tx_reset_queue() de virtnet_enable_queue_pair(). Esto elimina los bloqueos de BQL. Como resultado, netdev_tx_reset_queue() ahora se requiere explícitamente en la ruta de congelamiento/restauración. Este parche lo agrega inmediatamente después de free_unused_bufs(), siguiendo la regla general: netdev_tx_reset_queue() debe seguir cualquier liberación de SKB no seguida por netdev_tx_completed_queue(). Este parece ser el enfoque más consistente y optimizado, y ahora netdev_tx_reset_queue() se ejecuta siempre que se realiza free_unused_bufs(). [1]: ------------[ corte aquí ]------------ ¡ERROR del kernel en lib/dynamic_queue_limits.c:99! Oops: código de operación no válido: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 UID: 0 PID: 1598 Comm: ip Contaminado: GN 6.12.0net-next_main+ #2 Contaminado: [N]=TEST Nombre del hardware: QEMU Standard PC (Q35 + ICH9, 2009), \ BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dql_completed+0x26b/0x290 Código: b7 c2 49 89 e9 44 89 da 89 c6 4c 89 d7 e8 ed 17 47 00 58 65 ff 0d 4d 27 90 7e 0f 85 fd fe ff ff e8 ea 53 8d ff e9 f3 fe ff ff <0f> 0b 01 d2 44 89 d1 29 d1 ba 00 00 00 00 0f 48 ca e9 28 ff ff ff RSP: 0018:ffffc900002b0d08 EFLAGS: 00010297 RAX: 0000000000000000 RBX: ffff888102398c80 RCX: 0000000080190009 RDX: 0000000000000000 RSI: 000000000000006a RDI: 00000000000000000 RBP: ffff888102398c00 R08: 0000000000000000 R09: 0000000000000000 R10: 00000000000000ca R11: 0000000000015681 R12: 0000000000000001 R13: ffffc900002b0d68 R14: ffff88811115e000 R15: ffff8881107aca40 FS: 00007f41ded69500(0000) GS:ffff888667dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000556ccc2dc1a0 CR3: 0000000104fd8003 CR4: 0000000000772ef0 PKRU: 55555554 Rastreo de llamadas: ? die+0x32/0x80 ? do_trap+0xd9/0x100 ? dql_completed+0x26b/0x290 ? dql_completed+0x26b/0x290 ? do_error_trap+0x6d/0xb0 ? __actualizar_carga_avg_cfs_rq+0x264/0x2d0 ? reweight_entity+0x1be/0x260 __napi_poll.constprop.0+0x28/0x1c0 net_rx_action+0x329/0x420 ? enqueue_hrtimer+0x35/0x90 ? trace_hardirqs_on+0x1d/0x80 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? kvm_sched_clock_read+0xd/0x20 ? sched_clock+0xc/0x30 ? __local_bh_enable_ip+0xa7/0xb0 virtnet_open+0xc8/0x310 [virtio_net] __dev_open+0xfa/0x1b0 __dev_change_flags+0x1de/0x250 dev_change_flags+0x22/0x60 do_setlink.isra.0+0x2df/0x10b0 ? rtnetlink_rcv_msg+0x34f/0x3f0 ? netlink_rcv_skb+0x54/0x100 ? netlink_unicas ---truncado---

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: riscv: mm: No llamar a pmd dtor en el desmontaje de la tabla de páginas vmemmap Las tablas de páginas vmemmap, que se utilizan para RV64 con SPARSEMEM_VMEMMAP, se rellenan utilizando enormes tablas pmd (directorio intermedio de páginas). Sin embargo, la asignación de pmd no utiliza el mecanismo genérico utilizado por el código VMA (por ejemplo, pmd_alloc()), o el create_pgd_mapping()/alloc_pmd_late() específico de RISC-V. En su lugar, el código de la tabla de páginas vmemmap asigna una página y llama a vmemmap_set_pmd(). Esto da como resultado que el pmd ctor *no* se llame, ni tendría sentido hacerlo. Ahora, al desmantelar un pmd de la tabla de páginas vmemmap, el código de desinfección llamaría incondicional e incorrectamente al pmd dtor, lo que da como resultado un bloqueo (en el mejor de los casos). Este problema se encontró al ejecutar las autopruebas de HMM: | herramientas/pruebas/autopruebas/mm# ./test_hmm.sh smoke | ... # al descargar el módulo test_hmm.ko | página: refcount:1 mapcount:0 mapping:0000000000000000 índice:0x0 pfn:0x10915b | banderas: 0x1000000000000000(nodo=0|zona=1) | crudo: 1000000000000000 0000000000000000 dead0000000000122 0000000000000000 | raw: 0000000000000000 000000000000000 00000001ffffffff 0000000000000000 | página volcada porque: VM_BUG_ON_PAGE(ptdesc->pmd_huge_pte) | ------------[ cortar aquí ]------------ | ¡ERROR del kernel en include/linux/mm.h:3080! | ERROR del kernel [#1] | Módulos vinculados en: test_hmm(-) sch_fq_codel fuse drm drm_panel_orientation_quirks backlight dm_mod | CPU: 1 UID: 0 PID: 514 Comm: modprobe Contaminado: GW 6.12.0-00982-gf2a4f1682d07 #2 | Contaminado: [W]=WARN | Nombre del hardware: riscv-virtio qemu/qemu, BIOS 2024.10 10/01/2024 | epc : remove_pgd_mapping+0xbec/0x1070 | ra : remove_pgd_mapping+0xbec/0x1070 | epc : ffffffff80010a68 ra : ffffffff80010a68 sp : ff20000000a73940 | gp : ffffffff827b2d88 tp : ff6000008785da40 t0 : ffffffff80fbce04 | t1: 0720072007200720 t2: 706d756420656761 s0: ff20000000a73a50 | s1: ff6000008915cff8 a0: 0000000000000039 a1: 00000000000000008 | a2: ff600003fff0de20 a3: 0000000000000000 a4: 0000000000000000 | a5: 0000000000000000 a6: c0000000fffffff a7: ffffffff824469b8 | s2: ff1c0000022456c0 s3: ff1ffffffdbfffff s4: ff6000008915c000 | s5: ff6000008915c000 s6: ff6000008915c000 s7: ff1ffffffdc00000 | s8: 0000000000000001 s9: ff1ffffffdc00000 s10: ffffffff819a31f0 | s11: ffffffffffffffff t3: ffffffff8000c950 t4: ff60000080244f00 | t5 : ff60000080244000 t6 : ff20000000a73708 | estado: 0000000200000120 dirección incorrecta: ffffffff80010a68 causa: 0000000000000003 | [] eliminar_map_pgd+0xbec/0x1070 | [] vmemmap_free+0x14/0x1e | [] desactivar_sección+0x220/0x452 | [] eliminar_sección_sparse+0x4a/0x58 | [] __eliminar_páginas+0x7e/0xba | [] memunmap_páginas+0x2bc/0x3fe | [] dmirror_dispositivo_eliminar_fragmentos+0x2ea/0x518 [prueba_hmm] | [] hmm_dmirror_exit+0x3e/0x1018 [prueba_hmm] | [] __riscv_sys_eliminar_módulo+0x15a/0x2a6 | [] do_trap_ecall_u+0x1f2/0x266 | [] _new_vmalloc_restore_context_a0+0xc6/0xd2 | Código: bf51 7597 0184 8593 76a5 854a 4097 0029 80e7 2c00 (9002) 7597 | ---[ fin del seguimiento 000000000000000 ]--- | Pánico del kernel - no sincroniza: Excepción fatal en la interrupción Agregue una verificación para evitar llamar al dtor pmd, si el contexto de llamada es vmemmap_free().

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: blk-cgroup: corrige UAF en blkcg_unpin_online() blkcg_unpin_online() sube por la jerarquía blkcg y coloca el pin en línea. Para subir, usa blkcg_parent(blkcg) pero lo estaba llamando después de blkcg_destroy_blkgs(blkcg) que podría liberar el blkcg, lo que lleva al siguiente UAF: ====================================================================== ERROR: KASAN: slab-use-after-free en blkcg_unpin_online+0x15a/0x270 Lectura de tamaño 8 en la dirección ffff8881057678c0 por la tarea kworker/9:1/117 CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 No contaminado 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS desconocido 02/02/2022 Cola de trabajo: cgwb_release cgwb_release_workfn Seguimiento de llamadas: dump_stack_lvl+0x27/0x80 print_report+0x151/0x710 kasan_report+0xc0/0x100 blkcg_unpin_online+0x15a/0x270 cgwb_release_workfn+0x194/0x480 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 ... Liberado por la tarea 1944: kasan_save_track+0x2b/0x70 kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50 kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 Tenga en cuenta que el UAF no es fácil de activar ya que la ruta libre es Se produjo un error indirecto detrás de un par de períodos de gracia de RCU y una ejecución de elemento de trabajo. Solo pude activarlo con msleep() artificial inyectado en blkcg_unpin_online(). Solucione el problema leyendo el puntero principal antes de destruir los blkg de blkcg.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Arreglar UAF a través de la falta de coincidencia de los sabores de RCU de bpf_prog/attachment Los uprobes siempre usan bpf_prog_run_array_uprobe() bajo la protección de tareas-trace-RCU. Pero es posible adjuntar un programa BPF no durmiente a un uprobe, y los programas BPF no durmientes se liberan a través de RCU normal (ver __bpf_prog_put_noref()). Esto lleva a UAF de bpf_prog porque un período de gracia de RCU normal no implica un período de gracia de tareas-trace-RCU. Arréglelo esperando explícitamente un período de gracia de tareas-trace-RCU después de eliminar la conexión de un bpf_prog a un perf_event.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: usb: gadget: u_serial: soluciona el problema por el cual gs_start_io se bloqueaba debido al acceso a un puntero nulo. Teniendo en cuenta que en algunos casos extremos, cuando varios subprocesos acceden al controlador u_serial, el subproceso A ejecuta la operación de apertura y llama a gs_open, el subproceso B ejecuta la operación de desconexión y llama a la función gserial_disconnect, el puntero port->port_usb se establecerá en NULL. P. ej. Hilo A Hilo B gs_open() gadget_unbind_driver() gs_start_io() composite_disconnect() gs_start_rx() gserial_disconnect() ... ... spin_unlock(&port->port_lock) status = usb_ep_queue() spin_lock(&port->port_lock) spin_lock(&port->port_lock) port->port_usb = NULL gs_free_requests(port->port_usb->in) spin_unlock(&port->port_lock) Bloqueo Esto hace que el hilo A acceda a un puntero nulo (port->port_usb es nulo) al llamar a la función gs_free_requests, lo que provoca un bloqueo. Si port_usb es NULL, se omitirá la solicitud de liberación, ya que la realizará gserial_disconnect. Por lo tanto, agregue una verificación de puntero nulo a gs_start_io antes de intentar acceder al valor del puntero port->port_usb. Rastreo de llamadas: gs_start_io+0x164/0x25c gs_open+0x108/0x13c tty_open+0x314/0x638 chrdev_open+0x1b8/0x258 do_dentry_open+0x2c4/0x700 vfs_open+0x2c/0x3c path_openat+0xa64/0xc60 do_filp_open+0xb8/0x164 do_sys_openat2+0x84/0xf0 __arm64_sys_openat+0x70/0x9c invocar_syscall+0x58/0x114 el0_svc_common+0x80/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x38/0x68

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: gpio: graniterapids: Corregir fallo del controlador vGPIO Mover la configuración irq_chip.name de la función probe() a la inicialización de la estructura "irq_chip" para corregir el fallo del controlador vGPIO durante el arranque. El fallo fue causado por una modificación no autorizada del campo irq_chip.name donde la estructura irq_chip se inicializó como const. Este comportamiento es una consecuencia de la implementación subóptima de gpio_irq_chip_set_chip(), que debería cambiarse para evitar descartar el calificador const. Registro de fallos: ERROR: no se puede gestionar el error de página para la dirección: ffffffffc0ba81c0 /#PF: acceso de escritura del supervisor en modo kernel /#PF: error_code(0x0003) - violación de permisos CPU: 33 UID: 0 PID: 1075 Comm: systemd-udevd No contaminado 6.12.0-rc6-00077-g2e1b3cc9d7f7 #1 Nombre del hardware: Intel Corporation Kaseyville RP/Kaseyville RP, BIOS KVLDCRB1.PGS.0026.D73.2410081258 10/08/2024 RIP: 0010:gnr_gpio_probe+0x171/0x220 [gpio_graniterapids]