Vulnerabilidades

El repositorio de CodeQL CLI contiene archivos binarios para la interfaz de línea de comandos (CLI) de CodeQL. Antes de la versión 2.16.3, un analizador XML utilizado por la CLI de CodeQL para leer varios archivos auxiliares era vulnerable a un ataque de entidad externa XML. Si se utiliza una versión vulnerable de la CLI para procesar una base de datos CodeQL modificada maliciosamente o un conjunto especialmente preparado de fuentes de consulta QL, se puede hacer que la CLI realice una solicitud HTTP saliente a una URL que contenga material leído de un archivo local. elegido por el atacante. Esto puede resultar en una pérdida de privacidad o exfiltración de secretos. Los investigadores de seguridad y los autores de QL que reciben bases de datos o archivos fuente de QL de fuentes que no son de confianza pueden verse afectados. Un único archivo `.ql` o `.qll` que no sea de confianza no puede verse afectado, pero un archivo zip o tarball que contenga fuentes QL puede descomprimir archivos auxiliares que desencadenarán un ataque cuando CodeQL los vea en el sistema de archivos. Aquellos que usan CodeQL para análisis rutinarios de árboles fuente con un conjunto preseleccionado de consultas confiables no se ven afectados. En particular, extraer archivos XML de un árbol fuente a la base de datos CodeQL no lo hace vulnerable. El problema se solucionó en la versión 2.16.3 de CodeQL CLI. Además de actualizar, los workarounds incluyen no aceptar bases de datos CodeQL o consultas de fuentes no confiables, o solo procesar dicho material en una máquina sin conexión a Internet. Los clientes que utilicen versiones anteriores de CodeQL para el escaneo de seguridad en un sistema de CI automatizado y no puedan actualizar por motivos de cumplimiento pueden continuar usando esa versión. Ese caso de uso es seguro. Si dichos clientes tienen un paquete de consultas privado y usan el comando "codeql pack create" para precompilarlos antes de usarlos en el sistema CI, deberían usar la versión de producción de CodeQL para ejecutar "codeql pack create". Ese comando es seguro siempre que se confíe en la fuente QL que precompiló. Todos los demás desarrollos del paquete de consultas deben utilizar una CLI actualizada.

Tuleap es una suite de código abierto para mejorar la gestión de los desarrollos de software y la colaboración. Antes de la versión 15.5.99.76 de Tuleap Community Edition y antes de las versiones 15.5-4 y 15.4-7 de Tuleap Enterprise Edition, los usuarios con acceso de lectura a un rastreador donde se utiliza la función de actualización masiva podían obtener acceso a información restringida. Tuleap Community Edition 15.5.99.76, Tuleap Enterprise Edition 15.5-4 y Tuleap Enterprise Edition 15.4-7 contienen un parche para este problema.

Discourse Calendar agrega la capacidad de crear un calendario dinámico en la primera publicación de un tema en la plataforma de discusión de código abierto Discourse. Antes de la versión 0.4, cualquier persona puede recuperar los invitados a eventos creados en temas en categorías privadas o MP (mensajes privados), incluso si no han iniciado sesión. Este problema se resuelve en la versión 0.4 del complemento de calendario de discurso. Si bien no hay un workaround disponible, colocar el sitio detrás de `login_required` no permitirá que usuarios anónimos utilicen este endpoint, pero los usuarios que hayan iniciado sesión aún pueden obtener la lista de invitados en los temas privados.

SKINsoft S-Museum 7.02.3 permite la carga de archivos sin restricciones a través de la función Agregar medios. A diferencia de CVE-2024-25801, el payload del ataque es el contenido del archivo.

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Rechazar variable offset alu en PTR_TO_FLOW_KEYS Para PTR_TO_FLOW_KEYS, check_flow_keys_access() solo usa fijo para la validación. Sin embargo, el desplazamiento variable ptr alu no está prohibido para este tipo de ptr. Por lo tanto, el desplazamiento variable no se verifica. Se acepta el siguiente programa: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1; R1=ctx() R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flujo_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3: (37) r8 /= 1 ; R8_w=escalar() 4: (57) r8 &= 1024 ; R8_w=escalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 pila= antes de 4: (57) r8 &= 1024 mark_precise: frame0: regs=r8 pila= antes de 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 pila= antes de 2: (b7 ) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=escalar(smin=smin32=0,smax=umax=smax32= umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar() 7: (95) salida Este programa carga flow_keys en r7, agrega la variable offset r8 a r7 y finalmente causa acceso fuera de límites: ERROR: no se puede manejar el error de página para la dirección: ffffc90014c80038 [. ..] Seguimiento de llamadas: bpf_dispatcher_nop_func include/linux/bpf.h:1231 [en línea] __bpf_prog_run include/linux/filter.h:651 [en línea] bpf_prog_run include/linux/filter.h:658 [en línea] bpf_prog_run_pin_on_cpu include /linux/filter.h:675 [Inline] BPF_FLOW_DISSECT+0x15f/0x350 net/Core/Flow_Dissector.C: 991 BPF_Prog_Test_Run_Flow_Dissector+0x39D/0x620 NET/BPF/Test_Run.C: 1359 BPF_PRF_TISM 4107 [ en línea] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475 __do_sys_bpf kernel/bpf/syscall.c:5561 [en línea] __se_sys_bpf kernel/bpf/syscall.c:5559 [en línea] __x64_sys_bpf+0x73 /0xb0 kernel/bpf /syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+0x63/0x6b Solucionar esto rechazando ptr alu con variable compensación en flow_keys. La aplicación del parche rechaza el programa con "La aritmética de puntero R7 en flow_keys está prohibida".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: erofs: corrige el formato de compresión por archivo inconsistente EROFS puede seleccionar algoritmos de compresión por archivo, y cada algoritmo de compresión por archivo debe marcarse en el superbloque del disco para la inicialización. Sin embargo, syzkaller puede generar imágenes manipuladas inconsistentes que usan un tipo de algoritmo no compatible para inodos específicos, por ejemplo, usa el tipo de algoritmo MicroLZMA incluso si no está configurado en `sbi->available_compr_algs`. Esto puede provocar un "ERROR: desreferencia del puntero NULL del kernel" inesperado si el descompresor correspondiente no está integrado. Solucione este problema comprobando con `sbi->available_compr_algs` para cada solicitud de m_algorithmformat. El mapa de bits preestablecido !erofs_sb_has_compr_cfgs incorrecto ahora se corrige porque antes era inofensivo.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: Se corrigió la rama de re-adjunción en bpf_tracing_prog_attach El siguiente caso puede causar un bloqueo debido a la falta de adjunto_btf: 1) cargar el programa rawtp 2) cargar el programa fentry con rawtp como target_fd 3) crear enlace de seguimiento para el programa fentry con target_fd = 0 4) repetir 3 Al final tenemos: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (porque no proporcionamos target_fd para link_create) - prog->aux ->attach_btf == NULL (el programa se cargó con adjunto_prog_fd=X) - el programa se cargó para tgt_prog pero no tenemos forma de averiguar cuál ERROR: desreferencia del puntero NULL del núcleo, dirección: 0000000000000058 Seguimiento de llamadas: ? __morir+0x20/0x70 ? page_fault_oops+0x15b/0x430? fixup_exception+0x22/0x330? exc_page_fault+0x6f/0x170? asm_exc_page_fault+0x22/0x30? bpf_tracing_prog_attach+0x279/0x560? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 Entry_SYSCALL_64_after_hwframe+0x6e/ 0x76 Devuelve -EINVAL en esta situación.

En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ksmbd: soluciona problema de UAF en ksmbd_tcp_new_connection() La ejecución es entre el manejo de una nueva conexión TCP y su desconexión. Conduce a UAF en `struct tcp_transport` en la función ksmbd_tcp_new_connection().

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: apparmor: evita fallas cuando el nombre del perfil analizado está vacío Al procesar un perfil empaquetado en unpack_profile() descrito como "perfil :ns::samba-dcerpcd /usr/lib*/samba/ {,samba/}samba-dcerpcd {...}" una cadena ":samba-dcerpcd" se descomprime como un nombre completo y luego se pasa a aa_splitn_fqname(). aa_splitn_fqname() trata ":samba-dcerpcd" como si solo contuviera un espacio de nombres. Por lo tanto, devuelve NULL para tmpname, mientras que tmpns no es NULL. Más tarde, aa_alloc_profile() falla porque el nuevo nombre del perfil ahora es NULL. falla de protección general, probablemente para dirección no canónica 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref en rango [0x00000000000000000-0x0000000000000007] CPU: 6 PID: 1657 Comm: apparmor_parser No contaminado 6.7.0- rc2-dirty #16 Nombre del hardware: PC estándar QEMU (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 01/04/2014 RIP: 0010:strlen+0x1e/0xa0 Llamada Seguimiento: ? strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960 aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 Policy_update+0x261/0x370 perfil_replace+ 0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0 Entry_SYSCALL_64_after_hwframe+0x6e/0x76 ---[ end trace 0000000000000000 ]--- RIP: 0010:strlen+0x1e/0xa0 Parece que tal comportamiento de aa_splitn_fqname() se espera y se verifica en otros lugares donde se llama (por ejemplo, aa_remove_profiles). Bueno, hay un comentario explícito "se permite un nombre ns sin un perfil de seguimiento" dentro. AFAICS, nada puede evitar que el "nombre" descomprimido tenga un formato como ":samba-dcerpcd": se pasa desde el espacio de usuario. En tal caso, rechace el reemplazo completo del conjunto de perfiles e informe al usuario con EPROTO y un mensaje explicativo. Encontrado por el Centro de verificación de Linux (linuxtesting.org).

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: f2fs: corrección para evitar corrupción directa Como informó Al en link[1]: f2fs_rename() ... if (old_dir != new_dir && !whiteout) f2fs_set_link(old_inode, old_dir_entry, old_dir_page, new_dir); demás f2fs_put_page(old_dir_page, 0); Quiere el número correcto en el enlace ".." Y el cambio de nombre entre directorios mueve la fuente al nuevo padre, incluso si le hubieran pedido que dejara un espacio en blanco en el lugar anterior. [1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/ Con el siguiente caso de prueba, puede causar corrupción directa, debido a que no llamó a f2fs_set_link() para actualizar el enlace ".." al nuevo directorio . - mkdir -p dir/foo - renameat2 -w dir/foo bar [ASSERT] (__chk_dots_dentries:1421) --> Número de inodo incorrecto [0x4] para '..', el ino padre padre es [0x3] [FSCK] otro corrupto errores [falla]

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: medios: pvrusb2: corrige el use after free de desconexión de contexto. Al cargar el módulo, se crea un kthread dirigido a la función pvr2_context_thread_func, que puede llamar a pvr2_context_destroy y, por lo tanto, llamar a kfree() en el objeto de contexto. Sin embargo, eso podría suceder antes de que el controlador usb hub_event pueda notificar al controlador. Este parche agrega una verificación de cordura antes de la lectura no válida reportada por syzbot, dentro de la pila de llamadas de desconexión de contexto.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf: corrige una condición de ejecución entre btf_put() y map_free() Al ejecutar `./test_progs -j` en mi máquina virtual local con el último kernel, una vez encontré un error kasan como a continuación: [ 1887.184724] ERROR: KASAN: slab-use-after-free en bpf_rb_root_free+0x1f8/0x2b0 [ 1887.185599] Lectura del tamaño 4 en la dirección ffff888106806910 por tarea kworker/u12:2/2830 [ 1887.186498] [ 1887.186712] CPU: 3 PID: 2830 Comm: kworker/u12:2 Contaminado: G OEL 6.7.0-rc3-00699-g90679706d486-dirty #494 [1887.188034] Nombre de hardware: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0 -0-g155821a1990b-prebuilt.qemu.org 01/04/2014 [1887.189618] Cola de trabajo: events_unbound bpf_map_free_deferred [1887.190341] Seguimiento de llamadas: [1887.190666] [1887.190949] dump_stack_lv l+0xac/0xe0 [ 1887.191423] ? nf_tcp_handle_invalid+0x1b0/0x1b0 [1887.192019]? pánico+0x3c0/0x3c0 [ 1887.192449] print_report+0x14f/0x720 [ 1887.192930] ? preempt_count_sub+0x1c/0xd0 [1887.193459]? __virt_addr_valid+0xac/0x120 [1887.194004]? bpf_rb_root_free+0x1f8/0x2b0 [ 1887.194572] kasan_report+0xc3/0x100 [ 1887.195085] ? bpf_rb_root_free+0x1f8/0x2b0 [ 1887.195668] bpf_rb_root_free+0x1f8/0x2b0 [ 1887.196183] ? __bpf_obj_drop_impl+0xb0/0xb0 [1887.196736]? preempt_count_sub+0x1c/0xd0 [1887.197270]? preempt_count_sub+0x1c/0xd0 [1887.197802]? _raw_spin_unlock+0x1f/0x40 [ 1887.198319] bpf_obj_free_fields+0x1d4/0x260 [ 1887.198883] array_map_free+0x1a3/0x260 [ 1887.199380] bpf_map_free_deferred+0x7b/0xe0 [ 18 87.199943] Process_scheduled_works+0x3a2/0x6c0 [1887.200549] trabajador_thread+0x633/0x890 [1887.201047]? __kthread_parkme+0xd7/0xf0 [ 1887.201574] ? kthread+0x102/0x1d0 [ 1887.202020] kthread+0x1ab/0x1d0 [ 1887.202447] ? pr_cont_work+0x270/0x270 [1887.202954]? kthread_blkcg+0x50/0x50 [ 1887.203444] ret_from_fork+0x34/0x50 [ 1887.203914] ? kthread_blkcg+0x50/0x50 [ 1887.204397] ret_from_fork_asm+0x11/0x20 [ 1887.204913] [ 1887.204913] [ 1887.205209] [ 1887.205416] Asignado por tarea 2197: [1887.205881] kasan_set_track+0x3f/0x60 [1887.206366] __kasan_kmalloc +0x6e/0x80 [ 1887.206856] __kmalloc+0xac/0x1a0 [ 1887.207293] btf_parse_fields+0xa15/0x1480 [ 1887.207836] btf_parse_struct_metas+0x566/0x670 [ 1887.208387 ] btf_new_fd+0x294/0x4d0 [ 1887.208851] __sys_bpf+0x4ba/0x600 [ 1887.209292] __x64_sys_bpf+0x41 /0x50 [ 1887.209762] do_syscall_64+0x4c/0xf0 [ 1887.210222] Entry_SYSCALL_64_after_hwframe+0x63/0x6b [ 1887.210868] [ 1887.211074] Liberado por la tarea 36: [ 1887.21146 0] kasan_set_track+0x3f/0x60 [ 1887.211951] kasan_save_free_info+0x28/0x40 [ 1887.212485] ____kasan_slab_free+ 0x101/0x180 [ 1887.213027] __kmem_cache_free+0xe4/0x210 [ 1887.213514] btf_free+0x5b/0x130 [ 1887.213918] rcu_core+0x638/0xcc0 [ 1887.214347] __do_ softirq+0x114/0x37e El error ocurre en bpf_rb_root_free+0x1f8/0x2b0: 00000000000034c0 : ; { 34c0: f3 0f 1e fa endbr64 34c4: e8 00 00 00 00 callq 0x34c9 34c9: 55 pushq %rbp 34ca: 48 89 e5 movq %rsp, %rbp ... ; if (rec && rec->refcount_off >= 0 && 36aa: 4d 85 ed testq %r13, %r13 36ad: 74 a9 je 0x3658 36af: 49 8d 7d 10 leaq 0x10(%r13), %rdi 36b3 : e8 00 00 00 00 callq 0x36b8 <==== función kasan 36b8: 45 8b 7d 10 movl 0x10(%r13), %r15d <==== carga de uso después de liberación 36bc: 45 85 ff testl %r15d, %r15d 36bf: 78 8c js 0x364d Entonces el problema ---truncado---