Pokud jsou tyto chyby zneužity, mohou útočníkům umožnit získat neoprávněný přístup k citlivým informacím nebo obecně způsobit problémy
Před několika dny bylo oznámeno vydání opravných aktualizací pro Wasmtime 6.0.1, 5.0.1 a 4.0.1 , které řeší zranitelnost (již katalogizovanou pod CVE-2023-26489), jež byla klasifikována jako kritická.
Tato zranitelnost umožňuje organizaci zápisu dat do oblasti paměti mimo limity povolené pro izolovaný kód WebAssembly, což může útočník potenciálně zneužít k organizaci provádění svého kódu mimo izolované prostředí WASI.
Pro ty, kteří nejsou obeznámeni s Wasmtime, měli byste vědět, že se jedná o běhové prostředí pro spouštění aplikací WebAssembly s rozšířeními WASI (WebAssembly System Interface) jako normální samostatné aplikace.
Wasmtime je napsán v Rustu a zranitelnost je způsobena logickou chybou v definici pravidel lineárního adresování paměti v generátoru kódu Cranelift, který převádí mezilehlou reprezentaci nezávislou na hardwarových architekturách do spustitelného strojového kódu pro architekturu x86_64.
Ohledně opravené zranitelnosti se zmiňuje, že zejména pro aplikace WebAssembly byly vypočítávány 35bitové efektivní adresy namísto 33bitových adres povolených ve WebAssembly , což změnilo limit virtuální paměti povolené pro operace čtení a zápisu na 34 GB, zatímco nastavení prostředí sandbox poskytuje ochranu pro 6 GB základní adresy.
Generátor kódu společnosti Wasmtime, Cranelift, má chybu v cílech x86_64, kde by výpočet režimu adresy omylem vypočítal 35bitovou efektivní adresu namísto 33bitové efektivní adresy definované WebAssembly. Tato chyba znamená, že s výchozí konfigurací generování kódu mohla operace načítání/ukládání řízená wasm číst/zapisovat adresy až 35 bitů od základny lineární paměti.
V důsledku toho se pro čtení a zápis z aplikací WebAssembly zpřístupnil rozsah virtuální paměti o velikosti 6 až 34 GB ze základní adresy . Tato paměť může pojmout další prostředí WebAssembly nebo běhové komponenty WebAssembly.
Například (i32.load (i32.shl (local.get 0) (i32.const 3))), je načten z adresy WebAssembly $local0 << 3. Při překladu do Cranelift bude výpočet $local0 << 3 na 32bitová hodnota, je nula rozšířena na 64bitovou hodnotu a poté přidána k základní adrese lineární paměti. Cranelift by vygeneroval výpis ve tvaru movl(%base, %local0, 8), %dst, který vypočítá %base + %local0 << 3.
Chyba je zde ale v tom, že k výpočtu adresy dochází u 64bitových hodnot, kde $local0 << 3 mělo zkrátit adresu na 32bitovou hodnotu. To znamená, že %local0, který může použít až 32 bitů pro adresu, získá další 3 bity adresního prostoru, aby byl přístupný přes movl .
Konečně, protože se vždy doporučuje aktualizovat balíček na nejnovější dostupnou verzi , stojí za zmínku, že existuje několik možných řešení, která lze použít ke zmírnění tohoto problému, pokud aktualizace není možná.
Je zmíněno, že žádné z těchto řešení není ve výchozím nastavení zapnuto a vyžaduje explicitní konfiguraci:
- Pokud není možné aktualizovat verzi Wasmtime, je zmíněna možnost "Config::static_memory_maximum_size(0)", která umožňuje povinné oddělené kontroly libovolného lineárního přístupu k paměti jako řešení k zablokování chyby (má za následek výrazné snížení výkonu ).
- Další možností je použít nastavení "Config::static_memory_guard_size(1 < 36)" ke zvýšení počtu ochranných stránek (Guard Page, vyvolá výjimku při přístupu) umístěných v problematickém rozsahu virtuální paměti (vede k rezervaci velkého množství virtuálních paměti a omezení počtu souběžných aplikací WebAssembly).
- Pokud je možné použít hostitele jiného než x86_64, opraví to také tuto chybu. Tato chyba neovlivňuje například backend AArch64 Wasmtime nebo Cranelift.
A konečně, pokud máte zájem dozvědět se více, podrobnosti naleznete na následujícím odkazu.