Om de utnyttjas kan dessa brister tillåta angripare att få obehörig åtkomst till känslig information eller i allmänhet orsaka problem
För några dagar sedan den lWasmtime 6.0.1, 5.0.1 och 4.0.1 korrigerande uppdateringar släpptes que de får åtgärda en sårbarhet (redan katalogiserad under CVE-2023-26489) som bedömdes som kritisk.
Sårbarhet gör det möjligt att organisera skrivningen av data i ett minnesområde utanför de tillåtna gränserna för isolerad WebAssembly-kod, som potentiellt kan användas av en angripare för att orkestrera exekvering av deras kod utanför den isolerade WASI-miljön.
För de som inte är bekanta med Wasmtime bör du veta att detta är en körtid för att köra WebAssembly-applikationer med WASI-tillägg (WebAssembly System Interface) som vanliga fristående applikationer.
Wasmtime är skrivet i Rust och sårbarheten beror på ett logiskt fel i definitionen av routingregler av linjärt minne i Cranelift-kodgeneratorn, som översätter en mellanrepresentation oberoende av hårdvaruarkitekturer till exekverbar maskinkod för x86_64-arkitekturen.
Beträffande den fasta sårbarheten nämns att i synnerhet, effektiva 35-bitars adresser beräknades för WebAssembly-applikationer istället för de 33-bitars adresser som tillåts i WebAssembly, som ändrade gränsen för virtuellt minne som tillåts för läs- och skrivoperationer till 34 GB, medan miljöinställningen för sandlåde ger skydd för 6 GB. från basadressen.
Wasmtimes kodgenerator, Cranelift, har en bugg i x86_64-mål där adresslägesberäkningen av misstag skulle beräkna en 35-bitars effektiv adress istället för den 33-bitars effektiva adress som definierats av WebAssembly. Denna bugg innebär att, med standardkodgenereringskonfigurationen, kan en wasm-kontrollerad laddning/lagringsoperation läsa/skriva adresser upp till 35 bitar bort från basen av linjärt minne.
Som ett resultat det virtuella minnesintervallet från 6 till 34 GB från basadressen blev tillgängligt för läsning och skrivning från WebAssembly-applikationer. Detta minne kan innehålla andra WebAssembly-miljöer eller WebAssembly-runtime-komponenter.
Till exempel (i32.load (i32.shl (local.get 0) (i32.const 3))), laddas från WebAssembly-adressen $local0 << 3. När den översätts till Cranelift, beräkningen av $local0 << 3 till ett 32-bitars värde, nollexpanderas till ett 64-bitars värde och läggs sedan till basadressen för linjärt minne. Cranelift skulle generera en sats av formen movl(%base, %local0, 8), %dst som beräknar %base + %local0 << 3.
Felet här är dock att adressberäkningen sker med 64-bitars värden, där $local0 << 3 var tänkt att trunkera adressen till ett 32-bitars värde. Detta innebär att %local0, som kan använda upp till 32 bitar för en adress, får ytterligare 3 bitar adressutrymme för att vara tillgängligt via movl .
Slutligen, som alltid rekommenderas det att uppdatera paketet till den senaste tillgängliga versionenDet är också värt att nämna att det finns flera möjliga lösningar som kan användas för att lindra detta problem om uppdateringen inte är möjlig.
Det nämns att ingen av dessa lösningar är på som standard och kräver explicit konfiguration:
- Om det inte är möjligt att uppdatera versionen av Wasmtime, nämns alternativet "Config::static_memory_maximum_size(0)" för att möjliggöra obligatorisk separat kontroll av linjär minnesåtkomst som en lösning för att blockera felet (resulterar i en betydande prestandaförsämring ).
- Ett annat alternativ är att använda inställningen "Config::static_memory_guard_size(1 < 36)" för att öka antalet skyddssidor (Guard Page, kasta undantag vid åtkomst) som finns i det problematiska virtuella minnesområdet (leder till att reservera en stor mängd virtuellt minne minne och begränsa antalet samtidiga WebAssembly-applikationer).
- Om det är möjligt att använda en icke-x86_64-värd kommer det också att fixa detta fel. Denna bugg påverkar inte AArch64-backend av Wasmtime eller Cranelift, till exempel.
Slutligen Om du är intresserad av att veta mer om det, du kan kolla in detaljerna följande länk.