Gli aggiornamenti correttivi Wasmtime 6.0.1, 5.0.1 e 4.0.1 hanno risolto la vulnerabilità (CVE-2023-26489), alla quale è stato assegnato un livello di pericolo critico. La vulnerabilità consente la scrittura dei dati in un'area di memoria al di fuori dei limiti consentiti per il codice WebAssembly isolato, che potrebbe essere potenzialmente utilizzato da un utente malintenzionato per eseguire il proprio codice all'esterno dell'ambiente WASI isolato.
Wasmtime è un runtime per l'esecuzione di applicazioni WebAssembly con estensioni WASI (WebAssembly System Interface) come normali applicazioni autonome. Il toolkit è scritto nel linguaggio Rust e la vulnerabilità è causata da un errore logico nella definizione delle regole di indirizzamento della memoria lineare nel generatore di codice Cranelift, che traduce una rappresentazione intermedia indipendente dalle architetture hardware in codice macchina eseguibile per l'architettura x86_64.
In particolare, per le applicazioni WebAssembly, sono stati calcolati indirizzi effettivi a 35 bit invece degli indirizzi a 33 bit consentiti in WebAssembly, il che ha spostato il limite di memoria virtuale consentita per le operazioni di lettura e scrittura a 34 GB, mentre le impostazioni dell'ambiente sandbox forniscono protezione per 6 GB dall'indirizzo di base. Di conseguenza, l'intervallo di memoria virtuale compreso tra 6 e 34 GB dall'indirizzo di base era disponibile per la lettura e la scrittura dalle applicazioni WebAssembly. Questa memoria può ospitare altri ambienti WebAssembly o componenti runtime WebAssembly.
Se non è possibile aggiornare la versione Wasmtime, una soluzione alternativa per bloccare l'errore consiste nel specificare l'opzione "Config::static_memory_maximum_size(0)" per abilitare un controllo dei limiti separato su tutti gli accessi lineari alla memoria (con conseguente significativa riduzione delle prestazioni) . Un'altra opzione è utilizzare l'impostazione “Config::static_memory_guard_size(1 < 36)” per aumentare il numero di Guard Pages (un'eccezione generata quando si accede) posizionate nell'intervallo problematico di memoria virtuale (con conseguente riserva di una grande quantità di memoria virtuale e limitando il numero di applicazioni WebAssembly che eseguono simultaneamente).
Fonte: opennet.ru