Vulnerabilidades

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: xen-netback: toma una referencia al hilo de la tarea RX. Haga esto para evitar que la tarea se libere si el hilo regresa (que puede ser activado por el frontend) antes de que llamada a kthread_stop realizada como parte del desmontaje del backend. No tomar la referencia conducirá a un use-after-free en ese escenario. Esta referencia se tomó antes, pero se eliminó como parte de la revisión realizada en 2ac061ce97f4. Vuelva a introducir la toma de referencia y agregue esta vez un comentario explicando por qué es necesario. Este es XSA-374/CVE-2021-28691.

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ext4: corrigió el error en ext4_es_cache_extent ya que ext4_split_extent_at falló. Obtuvimos el seguimiento de bug_on cuando ejecutamos fsstress con la inyección de error de IO: [130747.323114] ERROR del kernel en fs/ext4/extents_status.c:762. [130747.323117] Error interno: Vaya - ERROR: 0 [#1] SMP ...... [130747.334329] Rastreo de llamadas: [130747.334553] ext4_es_cache_extent+0x150/0x168 [ext4] [130747.334975] ext4_cache_extents+0x 64/0xe8 [ext4] [130747.335368] text4_find_extent+0x300/0x330 [ext4] [130747.335759] text4_ext_map_blocks+0x74/0x1178 [ext4] [130747.336179] text4_map_blocks+0x2f4/0x5f0 [ext4] [130747.336567] ext4_mpage_readpages+0x4a8/0x7a8 [ext4] [130747.336995] ext4_readpage+0x54 /0x100 [ext4] [130747.337359] generic_file_buffered_read+0x410/0xae8 [130747.337767] generic_file_read_iter+0x114/0x190 [130747.338152] ext4_file_read_iter+0x5c/0x140 [ext4] [13 0747.338556] __vfs_read+0x11c/0x188 [130747.338851] vfs_read+0x94/0x150 [130747.339110 ] ksys_read+0x74/0xf0 La modificación de este parche se realiza según la sugerencia de Jan Kara en: https://patchwork.ozlabs.org/project/linux-ext4/patch/20210428085158.3728201-1-yebin10@huawei.com/ "Ya veo. Ahora Entiendo su parche. Honestamente, viendo lo frágil que es intentar arreglar el árbol de extensión después de que la división falló en el medio, probablemente iría aún más lejos y me aseguraría de arreglar el árbol correctamente en el caso de ENOSPC y EDQUOT (esos son fácilmente activables por el usuario). ). Cualquier otra cosa indica un problema de hardware o corrupción de fs, por lo que prefiero dejar el árbol de extensiones como está y no intentar arreglarlo (lo que también significa que no crearemos extensiones superpuestas)".

En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: pid: toma una referencia al inicializar `cad_pid` Durante el arranque, kernel_init_freeable() inicializa `cad_pid` en la estructura pid de la tarea de inicio. Más adelante, podemos cambiar `cad_pid` mediante un sysctl, y cuando esto suceda, proc_do_cad_pid() incrementará el recuento en el nuevo pid mediante get_pid(), y disminuirá el recuento en el pid antiguo mediante put_pid(). Como nunca llamamos a get_pid() cuando inicializamos `cad_pid`, disminuimos una referencia que nunca incrementamos, por lo que podemos liberar la estructura pid de la tarea de inicio antes. Como puede haber referencias pendientes a la estructura pid, más adelante podemos encontrarnos con un use-after-free (por ejemplo, al entregar señales). Esto se detectó al fusionar v5.13-rc3 con Syzkaller, pero parece haber existido desde la conversión de `cad_pid` a struct pid en el commit 9ec52099e4b8 ("[PATCH] reemplaza cad_pid por una estructura pid") del pre-KASAN edad de piedra de v2.6.19. Solucione este problema obteniendo una referencia a la estructura pid de la tarea de inicio cuando la asignamos a `cad_pid`. Símbolo completo de KASAN a continuación. ==================================================== ================ ERROR: KASAN: use-after-free en ns_of_pid include/linux/pid.h:153 [en línea] ERROR: KASAN: use-after-free en task_active_pid_ns +0xc0/0xc8 kernel/pid.c:509 Lectura de tamaño 4 en addr ffff23794dda0004 por tarea syz-executor.0/273 CPU: 1 PID: 273 Comm: syz-executor.0 No contaminado 5.12.0-00001-g9aef892b2d15 # 1 Nombre del hardware: linux,dummy-virt (DT) Rastreo de llamadas: ns_of_pid include/linux/pid.h:153 [en línea] task_active_pid_ns+0xc0/0xc8 kernel/pid.c:509 do_notify_parent+0x308/0xe60 kernel/signal.c :1950 exit_notify kernel/exit.c:682 [en línea] do_exit+0x2334/0x2bd0 kernel/exit.c:845 do_group_exit+0x108/0x2c8 kernel/exit.c:922 get_signal+0x4e4/0x2a88 kernel/signal.c:2781 do_signal arch/arm64/kernel/signal.c:882 [en línea] do_notify_resume+0x300/0x970 arch/arm64/kernel/signal.c:936 work_pending+0xc/0x2dc Asignado por tarea 0: slab_post_alloc_hook+0x50/0x5c0 mm/slab.h :516 slab_alloc_node mm/slub.c:2907 [en línea] slab_alloc mm/slub.c:2915 [en línea] kmem_cache_alloc+0x1f4/0x4c0 mm/slub.c:2920 alloc_pid+0xdc/0xc00 kernel/pid.c:180 copy_process+ 0x2794/0x5e18 kernel/fork.c:2129 kernel_clone+0x194/0x13c8 kernel/fork.c:2500 kernel_thread+0xd4/0x110 kernel/fork.c:2552 rest_init+0x44/0x4a0 init/main.c:687 arch_call_rest_init+0x1c/ 0x28 start_kernel+0x520/0x554 init/main.c:1064 0x0 Liberado por la tarea 270: slab_free_hook mm/slub.c:1562 [en línea] slab_free_freelist_hook+0x98/0x260 mm/slub.c:1600 slab_free mm/slub.c:3161 [en línea] kmem_cache_free+0x224/0x8e0 mm/slub.c:3177 put_pid.part.4+0xe0/0x1a8 kernel/pid.c:114 put_pid+0x30/0x48 kernel/pid.c:109 proc_do_cad_pid+0x190/0x1b0 kernel/ sysctl.c:1401 proc_sys_call_handler+0x338/0x4b0 fs/proc/proc_sysctl.c:591 proc_sys_write+0x34/0x48 fs/proc/proc_sysctl.c:617 call_write_iter include/linux/fs.h:1977 [en línea] new_sync_write+0x3ac/ 0x510 fs/read_write.c:518 vfs_write fs/read_write.c:605 [en línea] vfs_write+0x9c4/0x1018 fs/read_write.c:585 ksys_write+0x124/0x240 fs/read_write.c:658 __do_sys_write fs/read_write.c: 670 [en línea] __se_sys_write fs/read_write.c:667 [en línea] __arm64_sys_write+0x78/0xb0 fs/read_write.c:667 __invoke_syscall arch/arm64/kernel/syscall.c:37 [en línea] invoke_syscall arch/arm64/kernel/syscall .c:49 [en línea] el0_svc_common.constprop.1+0x16c/0x388 arch/arm64/kernel/syscall.c:129 do_el0_svc+0xf8/0x150 arch/arm64/kernel/syscall.c:168 el0_svc+0x28/0x38 arch/ arm64/kernel/entry-common.c:416 el0_sync_handler+0x134/0x180 arch/arm64/kernel/entry-common.c:432 el0_sync+0x154/0x180 arch/arm64/kernel/entry.S:701 La dirección del error pertenece a el objeto en ffff23794dda0000 que pertenece al pid de caché de tamaño 224.---truncado---

En el kernel de Linux, se resolvió la siguiente vulnerabilidad: ocfs2: corrige la corrupción de datos por fallocate Cuando fallocate perfora agujeros en el tamaño del inodo, si el isize original está en el medio del último clúster, entonces la parte desde isize hasta el final del clúster se pondrá a cero con la escritura en el búfer, en ese momento isize aún no se ha actualizado para que coincida con el nuevo tamaño, si se activa la reescritura, invocará ocfs2_writepage()->block_write_full_page() donde se eliminarán las páginas fuera del tamaño del inodo. Eso causará corrupción de archivos. Solucione este problema poniendo a cero los bloques eof al extender el tamaño del inodo. Ejecutar el siguiente comando con qemu-image 4.2.1 puede obtener fácilmente un archivo de imagen corrupto y convertido. qemu-img convert -p -t none -T none -f qcow2 $qcow_image \ -O qcow2 -o compat=1.1 $qcow_image.conv El uso de fallocate en qemu es así, primero perfora agujeros en el tamaño del inodo, luego ampliar el tamaño del inodo. fallocate(11, FALLOC_FL_KEEP_SIZE|FALLOC_FL_PUNCH_HOLE, 2276196352, 65536) = 0 fallocate(11, 0, 2276196352, 65536) = 0 v1: https://www.spinics.net/lists/linux-fsdevel/msg193999.html v2: https //lore.kernel.org/linux-fsdevel/20210525093034.GB4112@quack2.suse.cz/T/

OpenMetadata es una plataforma unificada para el descubrimiento, la observabilidad y la gobernanza impulsada por un repositorio central de metadatos, un linaje profundo y una colaboración fluida en equipo. El método `?AlertUtil::validateExpression` evalúa una expresión SpEL usando `getValue` que de forma predeterminada usa `StandardEvaluationContext`, permitiendo que la expresión alcance e interactúe con clases Java como `java.lang.Runtime`, lo que lleva al código remoto Ejecución. El endpoint `/api/v1/events/subscriptions/validation/condition/` pasa datos controlados por el usuario `AlertUtil::validateExpession`, lo que permite a los usuarios autenticados (no administradores) ejecutar comandos arbitrarios del sistema en el sistema operativo subyacente. Además, falta una verificación de autorización ya que `Authorizer.authorize()` nunca se llama en la ruta afectada y, por lo tanto, cualquier usuario no administrador autenticado puede activar este endpoint y evaluar expresiones SpEL arbitrarias que conduzcan a la ejecución de comandos arbitrarios. . Esta vulnerabilidad se descubrió con la ayuda de la consulta de inyección de lenguaje de expresión (Spring) de CodeQL y también se rastrea como "GHSL-2023-235". Este problema puede provocar la ejecución remota de código y se solucionó en la versión 1.2.4. Se recomienda a los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.

OpenMetadata es una plataforma unificada para el descubrimiento, la observabilidad y la gobernanza impulsada por un repositorio central de metadatos, un linaje profundo y una colaboración fluida en equipo. El `JwtFilter` maneja la autenticación API solicitando y verificando tokens JWT. Cuando llega una nueva solicitud, la ruta de la solicitud se compara con esta lista. Cuando la ruta de la solicitud contiene cualquiera de los endpoints excluidos, el filtro regresa sin validar el JWT. Desafortunadamente, un atacante puede usar parámetros de ruta para hacer que cualquier ruta contenga cadenas arbitrarias. Por ejemplo, una solicitud para `GET /api/v1;v1%2fusers%2flogin/events/subscriptions/validation/condition/111` coincidirá con la condición del endpoint excluido y, por lo tanto, se procesará sin validación JWT, lo que permitirá a un atacante eludir el mecanismo de autenticación y llegar a cualquier endpoint arbitrario, incluidos los enumerados anteriormente que conducen a la inyección de expresión SpEL arbitraria. Esta omisión no funcionará cuando el endpoint utilice `SecurityContext.getUserPrincipal()` ya que devolverá `null` y generará un NPE. Este problema puede provocar una omisión de autenticación y se solucionó en la versión 1.2.4. Se recomienda a los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad. Este problema también se rastrea como "GHSL-2023-237".

OpenMetadata es una plataforma unificada para el descubrimiento, la observabilidad y la gobernanza impulsada por un repositorio central de metadatos, un linaje profundo y una colaboración fluida en equipo. De manera similar al problema GHSL-2023-250, `AlertUtil::validateExpression` también se llama desde `EventSubscriptionRepository.prepare()`, lo que puede conducir a la ejecución remota de código. `prepare()` se llama desde `EntityRepository.prepareInternal()` que, a su vez, se llama desde `EntityResource.createOrUpdate()`. Tenga en cuenta que, aunque hay una verificación de autorización (`authorizer.authorize()`), se llama después de que se llama a `prepareInternal()` y, por lo tanto, después de que se haya evaluado la expresión SpEL. Para llegar a este método, un atacante puede enviar una solicitud PUT a `/api/v1/events/subscriptions` que es manejada por `EventSubscriptionResource.createOrUpdateEventSubscription()`. Esta vulnerabilidad se descubrió con la ayuda de la consulta de inyección de lenguaje de expresión (Spring) de CodeQL. Este problema puede provocar la ejecución remota de código y se solucionó en la versión 1.2.4. Se recomienda a los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad. Este problema también se rastrea como "GHSL-2023-251".

OpenMetadata es una plataforma unificada para el descubrimiento, la observabilidad y la gobernanza impulsada por un repositorio central de metadatos, un linaje profundo y una colaboración fluida en equipo. El método `?CompiledRule::validateExpression` evalúa una expresión SpEL usando un `StandardEgressionContext`, permitiendo que la expresión alcance e interactúe con clases Java como `java.lang.Runtime`, lo que lleva a la ejecución remota de código. El endpoint `/api/v1/policies/validation/condition/` pasa datos controlados por el usuario `CompiledRule::validateExpession`, lo que permite a los usuarios autenticados (no administradores) ejecutar comandos arbitrarios del sistema en el sistema operativo subyacente. Además, falta una verificación de autorización ya que `Authorizer.authorize()` nunca se llama en la ruta afectada y, por lo tanto, cualquier usuario no administrador autenticado puede activar este endpoint y evaluar expresiones SpEL arbitrarias que conduzcan a la ejecución de comandos arbitrarios. Esta vulnerabilidad se descubrió con la ayuda de la consulta de inyección de lenguaje de expresión (Spring) de CodeQL y también se rastrea como "GHSL-2023-236". Este problema puede provocar la ejecución remota de código y se resolvió en la versión 1.2.4. Se recomienda a los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.

En Django 3.2 anterior a 3.2.25, 4.2 anterior a 4.2.11 y 5.0 anterior a 5.0.3, el método django.utils.text.Truncator.words() (con html=True) y el filtro de plantilla truncatewords_html están sujetos a un potencial Ataque de denegación de servicio de expresión regular a través de una cadena manipulada. NOTA: este problema existe debido a una solución incompleta para CVE-2019-14232 y CVE-2023-43665.

projectdiscovery/nuclei es un escáner de vulnerabilidades rápido y personalizable basado en DSL simple basado en YAML. Se identificó un importante descuido de seguridad en Nuclei v3, que implica la ejecución de plantillas de código sin firmar a través de flujos de trabajo. Esta vulnerabilidad afecta específicamente a los usuarios que utilizan flujos de trabajo personalizados, lo que potencialmente permite la ejecución de código malicioso en el sistema del usuario. Este aviso describe a los usuarios afectados, proporciona detalles sobre el parche de seguridad y sugiere estrategias de mitigación. La vulnerabilidad se aborda en Nuclei v3.2.0. Se recomienda encarecidamente a los usuarios que actualicen a esta versión para mitigar el riesgo de seguridad. Los usuarios deben abstenerse de utilizar flujos de trabajo personalizados si no pueden actualizar inmediatamente. Sólo se deben ejecutar flujos de trabajo confiables y verificados.

Discourse es una plataforma de código abierto para el debate comunitario. En las versiones afectadas, un atacante puede descubrir que existen categorías secretas cuando tienen fondos configurados. El problema está solucionado en la última versión estable, beta y probada de Discourse. Se recomienda a los usuarios que actualicen. Los usuarios que no puedan actualizar deben eliminar temporalmente los fondos de las categorías.

OpenMetadata es una plataforma unificada para el descubrimiento, la observabilidad y la gobernanza impulsada por un repositorio central de metadatos, un linaje profundo y una colaboración fluida en equipo. `CompiledRule::validateExpression` también se llama desde `PolicyRepository.prepare`. `prepare()` se llama desde `EntityRepository.prepareInternal()` que, a su vez, se llama desde `EntityResource.createOrUpdate()`. Tenga en cuenta que aunque hay una verificación de autorización (`authorizer.authorize()`), se llama después de que se llama a `prepareInternal()` y, por lo tanto, después de que se haya evaluado la expresión SpEL. Para llegar a este método, un atacante puede enviar una solicitud PUT a `/api/v1/policies` que es manejada por `PolicyResource.createOrUpdate()`. Esta vulnerabilidad se descubrió con la ayuda de la consulta de inyección de lenguaje de expresión (Spring) de CodeQL y también se rastrea como "GHSL-2023-252". Este problema puede provocar la ejecución remota de código y se solucionó en la versión 1.3.1. Se recomienda a los usuarios que actualicen. No se conocen workarounds para esta vulnerabilidad.