Si se explotan, estas fallas pueden permitir a los atacantes obtener acceso no autorizado a información confidencial o, en general, causar problemas
Hace pocos días se dio a conocer el lanzamiento de las actualizaciones correctivas de Wasmtime 6.0.1, 5.0.1 y 4.0.1 que llegan a solucionan una vulnerabilidad (ya catalogada bajo CVE-2023-26489) que se calificó como crítica.
La vulnerabilidad permite organizar la escritura de datos en un área de memoria fuera de los límites permitidos para el código WebAssembly aislado, que potencialmente puede ser utilizado por un atacante para organizar la ejecución de su código fuera del entorno WASI aislado.
Para quienes desconocen de Wasmtime, deben saber que este es un tiempo de ejecución para ejecutar aplicaciones WebAssembly con extensiones WASI (WebAssembly System Interface) como aplicaciones independientes normales.
Wasmtime está escrito en Rust y la vulnerabilidad se debe a un error lógico en la definición de reglas de direccionamiento de memoria lineal en el generador de código Cranelift, que traduce una representación intermedia independiente de las arquitecturas de hardware en un código de máquina ejecutable para la arquitectura x86_64.
Sobre la vulnerabilidad corregida, se menciona que en particular, se calcularon direcciones efectivas de 35 bits para las aplicaciones de WebAssembly en lugar de las direcciones de 33 bits permitidas en WebAssembly, lo que cambió el límite de memoria virtual permitida para operaciones de lectura y escritura a 34 GB, mientras que la configuración del entorno de espacio aislado proporciona protección para 6 GB. de la dirección base.
El generador de código de Wasmtime, Cranelift, tiene un error en los objetivos x86_64 donde el cálculo del modo de dirección calcularía por error una dirección efectiva de 35 bits en lugar de la dirección efectiva de 33 bits definida por WebAssembly. Este error significa que, con la configuración de generación de código predeterminada, una operación de carga/almacenamiento controlada por wasm podría leer/escribir direcciones de hasta 35 bits de distancia de la base de la memoria lineal.
Como resultado, el rango de memoria virtual de 6 a 34 GB desde la dirección base estuvo disponible para lectura y escritura desde aplicaciones WebAssembly. Esta memoria puede albergar otros entornos de WebAssembly o componentes de tiempo de ejecución de WebAssembly.
Por ejemplo (i32.load (i32.shl (local.get 0) (i32.const 3))), se carga desde la dirección WebAssembly $local0 << 3. Cuando se traduce a Cranelift, el calculo de $local0 << 3 en un valor de 32 bits, se amplía a cero a un valor de 64 bits y luego se agrega a la dirección base de la memoria lineal. Cranelift generaría una instrucción de la forma movl (%base, %local0, 8), %dst que calcula %base + %local0 << 3.
El error aquí, sin embargo, es que el cálculo de la dirección ocurre con valores de 64 bits, donde $local0 << 3 se suponía que el cálculo se truncaba a un valor de 32 bits. Esto significa que %local0, que puede usar hasta 32 bits para una dirección, obtiene 3 bits adicionales de espacio de direcciones para ser accesible a través de movl .
Por último, como siempre se recomienda actualizar la paquetería a la última versión disponible, tambien vale la pena mencionar que existen varias soluciones posibles que se pueden emplear para mitigar este problema si la actualización no es posible.
Se menciona que ninguna de estas soluciones está activada de forma predeterminada y requiere una configuración explícita:
- Si no es posible actualizar la versión de Wasmtime, se menciona la opción «Config::static_memory_maximum_size(0)» para habilitar la verificación de límites separados obligatorios en cualquier acceso a la memoria lineal como solución alternativa para bloquear el error (da como resultado una degradación significativa del rendimiento).
- Otra opción es utilizar la configuración «Config::static_memory_guard_size(1 < 36)» para aumentar la cantidad de páginas de protección (Página de protección, se lanza una excepción cuando se accede) ubicadas en el rango de memoria virtual problemático (conduce a reservar una gran cantidad de memoria virtual y limitando el número de aplicaciones WebAssembly concurrentes).
- Si es posible usar un host que no sea x86_64, eso también solucionará este error. Este error no afecta al backend AArch64 de Wasmtime o Cranelift, por ejemplo.
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.