Si s'exploten, aquestes falles poden permetre als atacants obtenir accés no autoritzat a informació confidencial o, en general, causar problemes
Fa pocs dies es va donar a conèixer elançament de les actualitzacions correctives de Wasmtime 6.0.1, 5.0.1 i 4.0.1 que arriben a solucionen una vulnerabilitat (ja catalogada sota CVE-2023-26489) que es va qualificar com a crítica.
la vulnerabilitat permet organitzar l'escriptura de dades en una àrea de memòria fora dels límits permesos per al codi WebAssembly aïllat, que potencialment pot ser utilitzat per un atacant per organitzar lexecució del seu codi fora de lentorn WASI aïllat.
Per als que desconeixen de Wasmtime, heu de saber que aquest és un temps d'execució per executar aplicacions WebAssembly amb extensions WASI (WebAssembly System Interface) com a aplicacions independents normals.
Wasmtime està escrit a Rust i la vulnerabilitat és deguda a un error lògic en la definició de regles d'encaminament de memòria lineal al generador de codi Cranelift, que tradueix una representació intermèdia independent de les arquitectures de maquinari en un codi de màquina executable per a l'arquitectura x86_64.
Sobre la vulnerabilitat corregida, es menciona que en particular, es van calcular adreces efectives de 35 bits per a les aplicacions de WebAssembly en lloc de les adreces de 33 bits permeses a WebAssembly, el que va canviar el límit de memòria virtual permesa per a operacions de lectura i escriptura a 34 GB, mentre que la configuració de lentorn despai aïllat proporciona protecció per 6 GB. de la direcció base.
El generador de codi de Wasmtime, Cranelift, té un error als objectius x86_64 on el càlcul del mode de direcció calcularia per error una adreça efectiva de 35 bits en lloc de la direcció efectiva de 33 bits definida per WebAssembly. Aquest error significa que, amb la configuració de generació de codi predeterminada, una operació de càrrega/emmagatzematge controlada per wasm podria llegir/escriure adreces de fins a 35 bits de distància de la base de la memòria lineal.
Com a resultat, el rang de memòria virtual de 6 a 34 GB des de l'adreça base va estar disponible per a lectura i escriptura des d'aplicacions WebAssembly. Aquesta memòria pot contenir altres entorns de WebAssembly o components de temps d'execució de WebAssembly.
Per exemple (i32.load (i32.shl (local.get 0) (i32.const 3))), es carrega des de l'adreça WebAssembly $local0 << 3. Quan es tradueix a Cranelift, el càlcul de $local0 << 3 en un valor de 32 bits, s'amplia a zero a un valor de 64 bits i després s'afegeix a la direcció base de la memòria lineal. Cranelift generaria una instrucció de la forma movl (%base, %local0, 8), %dst que calcula %base + %local0 << 3.
L'error aquí, però, és que el càlcul de la direcció passa amb valors de 64 bits, on $local0 << 3 se suposava que el càlcul es truncava a un valor de 32 bits. Això vol dir que %local0, que pot utilitzar fins a 32 bits per a una adreça, obté 3 bits addicionals d'espai d'adreces per ser accessible a través de movl .
Finalment, com sempre es recomana actualitzar la paqueteria a la darrera versió disponible, també val la pena esmentar que hi ha diverses solucions possibles que es poden emprar per mitigar aquest problema si l'actualització no és possible.
S'esmenta que cap d'aquestes solucions està activada per defecte i requereix una configuració explícita:
- Si no és possible actualitzar la versió de Wasmtime, s'esmenta l'opció «Config::static_memory_maximum_size(0)» per habilitar la verificació de límits separats obligatoris a qualsevol accés a la memòria lineal com a solució alternativa per bloquejar l'error (dóna com a resultat una degradació significativa del rendiment).
- Una altra opció és utilitzar la configuració «Config::static_memory_guard_size(1 < 36)» per augmentar la quantitat de pàgines de protecció (Pàgina de protecció, es llança una excepció quan s'accedeix) ubicades al rang de memòria virtual problemàtic (condueix a reservar gran quantitat de memòria virtual i limitant el nombre d'aplicacions WebAssembly concurrents).
- Si és possible fer servir un host que no sigui x86_64, això també solucionarà aquest error. Aquest error no afecta el backend AArch64 de Wasmtime o Cranelift, per exemple.
Finalment si estàs interessat en poder conèixer més a l'respecte, pots consultar els detalls a el següent enllaç.