CVE-2021-32629

Cranelift es un generador de código abierto mantenido por Bytecode Alliance. Traduce una representación intermedia independiente del objetivo en código máquina ejecutable. Hay un error en la versión 0.73 del backend de Cranelift x64 que puede crear un escenario que podría dar lugar a una potencial fuga de la caja de arena en un programa Wasm. Este error se introdujo en el nuevo backend el 2020-09-08 y se incluyó por primera vez en una versión el 2020-09-30, pero el nuevo backend no era el predeterminado antes de 0.73. La versión 0.73 recientemente lanzada con la configuración por defecto, y las versiones anteriores con una bandera de construcción explícita para seleccionar el nuevo backend, son vulnerables. El fallo en cuestión realiza un signo-extensión en lugar de un cero-extensión en un valor cargado desde la pila, bajo un conjunto específico de circunstancias. Si se dan esas circunstancias, el fallo podría permitir el acceso a direcciones de memoria de hasta 2GiB antes del inicio de la pila del programa Wasm. Si el límite del heap es mayor que 2GiB, entonces sería posible leer memoria de un rango computable dependiente del tamaño del límite del heaps. El impacto de este error depende en gran medida de la implementación de la pila, específicamente: * si el heap tiene comprobaciones de límites, y * no depende exclusivamente de páginas de guardia, y * el límite del heap es de 2GiB o menor * entonces este fallo no puede ser usado para alcanzar memoria desde otro heap del programa Wasm. El impacto de la vulnerabilidad se mitiga si no hay memoria mapeada en el rango accesible usando este bug, por ejemplo, si hay una región de guardia de 2 GiB antes del heap del programa Wasm. El fallo en cuestión realiza un signo-extensión en lugar de un cero-extensión en un valor cargado desde la pila, cuando el asignador de registros recarga un valor entero derramado más estrecho que 64 bits. Esto interactúa mal con otra optimización: el selector de instrucciones elude un operador de extensión a cero de 32 a 64 bits cuando sabemos que una instrucción que produce un valor de 32 bits realmente pone a cero los 32 bits superiores de su registro de destino. Por lo tanto, nos basamos en estos bits a cero, pero el tipo del valor sigue siendo i32, y el derrame/recarga reconstituye esos bits como la extensión del signo del MSB de i32. Por lo tanto, el problema ocurriría cuando: * Un valor i32 en un programa Wasm es mayor o igual a 0x8000_0000; * El valor es derramado y recargado por el asignador de registros debido a la alta presión de registros en el programa entre la definición del valor y su uso; * El valor es producido por una instrucción que sabemos que es "especial" en el sentido de que pone a cero los 32 bits superiores de su destino: add, sub, mul, and, or; * El valor es entonces extendido a cero a 64 bits en el programa Wasm; * El valor de 64 bits resultante es utilizado. Bajo estas circunstancias hay un potencial escape de la caja de arena cuando el valor i32 es un puntero. El código habitual emitido para los accesos al heap extiende a cero la dirección del heap de Wasm, la añade a una base del heap de 64 bits, y accede a la dirección resultante. Si el zero-extend se convierte en un sign-extend, el programa podría llegar hacia atrás y acceder a la memoria hasta 2GiB antes del inicio de su heap. Además de evaluar la naturaleza del fallo de generación de código en Cranelift, también hemos determinado que, en circunstancias específicas, tanto Lucet como Wasmtime que utilizan esta versión de Cranelift pueden ser explotables. Consulte el aviso de GitHub mencionado para obtener más detalles