Vulnerabilidades

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 1.123.18 y 2.5.0, una vulnerabilidad en los controles de acceso a archivos permite a usuarios autenticados con permiso para crear o modificar flujos de trabajo leer archivos sensibles del sistema anfitrión de n8n. Esto puede ser explotado para obtener datos de configuración críticos y credenciales de usuario, lo que lleva a una toma de control completa de la cuenta de cualquier usuario en la instancia. Este problema ha sido parcheado en las versiones 1.123.18 y 2.5.0.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 1.123.10 y 2.5.0, las vulnerabilidades en el nodo Git permitían a usuarios autenticados con permiso para crear o modificar flujos de trabajo ejecutar comandos de sistema arbitrarios o leer archivos arbitrarios en el host de n8n. Este problema ha sido parcheado en las versiones 1.123.10 y 2.5.0.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 1.123.12 y 2.4.0, cuando los flujos de trabajo procesan archivos cargados y los transfieren a servidores remotos a través del nodo SSH sin validar sus metadatos, la vulnerabilidad puede llevar a que los archivos se escriban en ubicaciones no deseadas en esos sistemas remotos, lo que podría llevar a la ejecución remota de código en esos sistemas. Como prerrequisito, un atacante no autenticado necesita conocimiento de la existencia de dichos flujos de trabajo y los puntos finales para la carga de archivos deben estar no autenticados. Este problema ha sido parcheado en las versiones 1.123.12 y 2.4.0.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de la versión 2.4.8, una vulnerabilidad en el nodo de Código Python permite a los usuarios autenticados escapar del entorno sandbox de Python y ejecutar código fuera del límite de seguridad previsto. Este problema ha sido parcheado en la versión 2.4.8.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de las versiones 1.123.17 y 2.5.2, un usuario autenticado con permiso para crear o modificar flujos de trabajo podría abusar de expresiones manipuladas en los parámetros del flujo de trabajo para desencadenar la ejecución no intencionada de comandos del sistema en el host que ejecuta n8n. Este problema ha sido parcheado en las versiones 1.123.17 y 2.5.2.

n8n es una plataforma de automatización de flujos de trabajo de código abierto. Antes de la versión 1.123.2, se ha identificado una vulnerabilidad de cross-site scripting (XSS) en el manejo de respuestas de webhook y puntos finales HTTP relacionados. Bajo ciertas condiciones, la protección sandbox de la Política de Seguridad de Contenido (CSP) destinada a aislar respuestas HTML puede no aplicarse correctamente. Un usuario autenticado con permiso para crear o modificar flujos de trabajo podría abusar de esto para ejecutar scripts maliciosos con privilegios de mismo origen cuando otros usuarios interactúan con el flujo de trabajo manipulado. Esto podría llevar a secuestro de sesión y toma de control de cuenta. Este problema ha sido parcheado en la versión 1.123.2.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: arm64/fpsimd: señal: Corrección de la restauración del contexto SVE Cuando SME es compatible, la restauración del contexto de señal SVE puede salir mal de varias maneras, incluyendo colocar la tarea en un estado inválido donde el kernel puede leer de memoria fuera de límites (y puede potencialmente sufrir una falla fatal) y/o puede terminar la tarea con un SIGKILL. (1) Restaurar un contexto con SVE_SIG_FLAG_SM establecido puede colocar la tarea en un estado inválido donde SVCR.SM está establecido (y sve_state no es NULL) pero TIF_SME está despejado, lo que consecuentemente resulta en lecturas de memoria fuera de límites y/o la terminación de la tarea con SIGKILL. Esto solo puede ocurrir en casos inusuales (pero legítimos) donde el contexto de señal SVE ha sido modificado por el espacio de usuario o fue guardado en el contexto de otra tarea (p. ej., como con CRIU), ya que de lo contrario la presencia de un contexto de señal SVE con SVE_SIG_FLAG_SM implica que TIF_SME ya está establecido. Mientras en este estado, task_fpsimd_load() NO configurará SMCR_ELx (dejando algún valor arbitrario configurado en hardware) antes de restaurar SVCR e intentar restaurar los registros SVE en modo streaming desde la memoria a través de sve_load_state(). Como el valor de SMCR_ELx.LEN puede ser mayor que la longitud del vector SVE en modo streaming de la tarea, esto puede leer memoria fuera del sve_state asignado a la tarea, leyendo datos no relacionados y/o desencadenando una falla. Si bien esto puede resultar en la carga de secretos en los registros SVE en modo streaming, estos valores nunca son expuestos. Como TIF_SME está despejado, fpsimd_bind_task_to_cpu() configurará CPACR_ELx.SMEN para atrapar accesos EL0 a los registros SVE en modo streaming, por lo que estos no pueden ser accedidos directamente en EL0. Como fpsimd_save_user_state() verifica la longitud del vector en vivo antes de guardar el estado (S)SVE en memoria, ningún valor secreto puede ser guardado de nuevo en memoria (y por lo tanto no puede ser observado a través de ptrace, señales, etc.). Cuando la longitud del vector en vivo no coincide con la longitud del vector esperada para la tarea, fpsimd_save_user_state() enviará una señal SIGKILL fatal a la tarea. Por lo tanto, la tarea puede ser terminada después de ejecutar el espacio de usuario por algún período de tiempo. (2) Restaurar un contexto con SVE_SIG_FLAG_SM despejado no despeja el SVCR.SM de la tarea. Si SVCR.SM estaba establecido antes de restaurar el contexto, entonces la tarea quedará en modo streaming inesperadamente, y algún estado de registro se combinará de manera inconsistente, aunque la tarea quedará en un estado legítimo desde el punto de vista del kernel. Esto solo puede ocurrir en casos inusuales (pero legítimos) donde ptrace ha sido usado para establecer SVCR.SM después de la entrada a la llamada al sistema sigreturn, ya que la entrada a la llamada al sistema despeja SVCR.SM. En estos casos, los datos de registro SVE proporcionados se cargarán en el sve_state de la tarea usando la longitud del vector SVE no-streaming y los registros FPSIMD se fusionarán en esto usando la longitud del vector SVE en modo streaming. Solución para (1) estableciendo TIF_SME al establecer SVCR.SM. Esto también requiere asegurar que el sme_state de la tarea ha sido asignado, pero como esto podría contener estado ZA en vivo, no debe ser puesto a cero. Solución para (2) despejando SVCR.SM al restaurar un contexto de señal SVE con SVE_SIG_FLAG_SM despejado. Para consistencia, he adelantado la manipulación de SVCR, TIF_SVE, TIF_SME y fp_type, inmediatamente después de la asignación de sve_state/sme_state, antes de la restauración del estado de registro real. Esto facilita asegurar que estos siempre se modifiquen de manera consist

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ipvlan: Hacer que el addrs_lock sea por puerto<br /> <br /> Hacer que el addrs_lock sea por puerto, no por dispositivo ipvlan.<br /> <br /> El código inicial parece estar escrito bajo la suposición de que cualquier cambio de dirección debe ocurrir bajo RTNL. Pero no es así para el caso de IPv6. Así que<br /> <br /> 1) Introducir addrs_lock por puerto.<br /> <br /> 2) Fue necesario corregir lugares donde se olvidó tomar el bloqueo (ipvlan_open/ipvlan_close)<br /> <br /> Esto parece ser un problema muy menor, sin embargo. Ya que es muy poco probable que ipvlan_add_addr() sea llamado en 2 CPU simultáneamente. Pero, sin embargo, esto podría causar:<br /> <br /> 1) Falso negativo de ipvlan_addr_busy(): una interfaz iteró a través de todos los port-&amp;gt;ipvlans + ipvlan-&amp;gt;addrs bajo algún spinlock de ipvlan, y otra añadió IP bajo su propio bloqueo. Aunque esto solo es posible para IPv6, ya que parece que solo ipvlan_addr6_event() puede ser llamado sin rtnl_lock.<br /> <br /> 2) Condición de carrera ya que ipvlan_ht_addr_add(port) es llamado bajo diferentes bloqueos ipvlan-&amp;gt;addrs_lock.<br /> <br /> Esto no debería afectar el rendimiento, ya que añadir/eliminar IP es una situación rara y el spinlock no se toma en rutas rápidas.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> ice: corrige el rastreo de llamadas de recarga de devlink<br /> <br /> El commit 4da71a77fc3b (&amp;#39;ice: read internal temperature sensor&amp;#39;) introdujo la lectura del sensor de temperatura interno a través de HWMON. ice_hwmon_init() se añadió a ice_init_feature() y ice_hwmon_exit() se añadió a ice_remove(). Como resultado, si se utiliza la recarga de devlink para reinicializar el dispositivo y luego se elimina el controlador, puede ocurrir un rastreo de llamadas.<br /> <br /> ERROR: no se puede manejar el fallo de página para la dirección: ffffffffc0fd4b5d<br /> Rastreo de Llamadas:<br /> string+0x48/0xe0<br /> vsnprintf+0x1f9/0x650<br /> sprintf+0x62/0x80<br /> name_show+0x1f/0x30<br /> dev_attr_show+0x19/0x60<br /> <br /> El rastreo de llamadas se repite aproximadamente cada 10 minutos cuando las herramientas de monitoreo del sistema (p. ej., sadc) intentan leer los atributos huérfanos de hwmon sysfs que referencian memoria de módulo liberada.<br /> <br /> La secuencia es:<br /> 1. Carga del controlador, ice_hwmon_init() es llamado desde ice_init_feature()<br /> 2. Recarga de Devlink hacia abajo, el flujo no llama a ice_remove()<br /> 3. Recarga de Devlink hacia arriba, ice_hwmon_init() es llamado desde ice_init_feature() resultando en una segunda instancia<br /> 4. Descarga del controlador, ice_hwmon_exit() llamado desde ice_remove() dejando la primera instancia de hwmon huérfana con un puntero colgante<br /> <br /> Solucione esto moviendo ice_hwmon_exit() de ice_remove() a ice_deinit_features() para asegurar una simetría de limpieza adecuada con ice_hwmon_init().

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> net/sched: qfq: Usar cl_is_active para determinar si la clase está activa en qfq_rm_from_ag<br /> <br /> Esto es más bien un parche preventivo para hacer el código más consistente y para prevenir posibles exploits que emplean manipulaciones de qlen secundarias en qfq.<br /> usar cl_is_active en lugar de depender del qlen del qdisc secundario para determinar la activación de la clase.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> gestión del tiempo: Ajustar el estado de salto para el gestor de tiempo auxiliar correcto<br /> <br /> Cuando se introdujo __do_ajdtimex() para manejar adjtimex para cualquier gestor de tiempo, esta referencia a tk_core no fue actualizada. Cuando se invocaba en un gestor de tiempo auxiliar, el gestor de tiempo principal se actualizaría incorrectamente.<br /> <br /> Esto es detectado por los diagnósticos de depuración de bloqueos porque el bloqueo de secuencia de los gestores de tiempo se escribe sin mantener su spinlock asociado:<br /> <br /> ADVERTENCIA: include/linux/seqlock.h:226 at __do_adjtimex+0x394/0x3b0, CPU#2: test/125<br /> aux_clock_adj (kernel/time/timekeeping.c:2979)<br /> __do_sys_clock_adjtime (kernel/time/posix-timers.c:1161 kernel/time/posix-timers.c:1173)<br /> do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))<br /> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:131)<br /> <br /> Actualizar el gestor de tiempo auxiliar correcto.

En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta:<br /> <br /> arm64/fpsimd: señal: Asignar almacenamiento SSVE al restaurar ZA<br /> <br /> El código para restaurar un contexto ZA no intenta asignar el sve_state de la tarea antes de establecer TIF_SME. En consecuencia, restaurar un contexto ZA puede colocar una tarea en un estado inválido donde TIF_SME está establecido pero el sve_state de la tarea es NULL.<br /> <br /> En casos legítimos pero poco comunes donde el contexto de señal ZA NO fue creado por el kernel en el contexto de la misma tarea (por ejemplo, si la tarea se guarda/restaura con algo como CRIU), no tenemos garantía de que sve_state se haya asignado previamente. En estos casos, el espacio de usuario puede entrar en modo de transmisión sin atrapar mientras sve_state es NULL, causando una desreferencia de puntero NULL posterior cuando el kernel intenta almacenar el estado del registro:<br /> <br /> | # ./sigreturn-za<br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000<br /> | Mem abort info:<br /> | ESR = 0x0000000096000046<br /> | EC = 0x25: DABT (current EL), IL = 32 bits<br /> | SET = 0, FnV = 0<br /> | EA = 0, S1PTW = 0<br /> | FSC = 0x06: level 2 translation fault<br /> | Data abort info:<br /> | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000<br /> | CM = 0, WnR = 1, TnD = 0, TagAccess = 0<br /> | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0<br /> | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00<br /> | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000<br /> | Internal error: Oops: 0000000096000046 [#1] SMP<br /> | Modules linked in:<br /> | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT<br /> | Hardware name: linux,dummy-virt (DT)<br /> | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--)<br /> | pc : sve_save_state+0x4/0xf0<br /> | lr : fpsimd_save_user_state+0xb0/0x1c0<br /> | sp : ffff80008070bcc0<br /> | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658<br /> | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000<br /> | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40<br /> | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000<br /> | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c<br /> | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020<br /> | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0<br /> | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48<br /> | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000<br /> | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440<br /> | Call trace:<br /> | sve_save_state+0x4/0xf0 (P)<br /> | fpsimd_thread_switch+0x48/0x198<br /> | __switch_to+0x20/0x1c0<br /> | __schedule+0x36c/0xce0<br /> | schedule+0x34/0x11c<br /> | exit_to_user_mode_loop+0x124/0x188<br /> | el0_interrupt+0xc8/0xd8<br /> | __el0_irq_handler_common+0x18/0x24<br /> | el0t_64_irq_handler+0x10/0x1c<br /> | el0t_64_irq+0x198/0x19c<br /> | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800)<br /> | ---[ end trace 0000000000000000 ]---<br /> <br /> Esto se soluciona haciendo que restore_za_context() asegure que el sve_state de la tarea esté asignado, coincidiendo con lo que hacemos al tomar una trampa SME. Cualquier estado SVE/SSVE activo (que se restaura anteriormente desde un contexto de señal separado) debe ser preservado, y por lo tanto no se pone a cero.