Als deze fouten worden misbruikt, kunnen aanvallers ongeoorloofde toegang krijgen tot gevoelige informatie of in het algemeen problemen veroorzaken
Een paar dagen geleden heeft de lWasmtime 6.0.1, 5.0.1 en 4.0.1 corrigerende updates uitgebracht dat ze mogen een kwetsbaarheid repareren (reeds gecatalogiseerd onder CVE-2023-26489) die als kritisch werd beoordeeld.
Kwetsbaarheid maakt het mogelijk om het schrijven van gegevens in een geheugengebied buiten de toegestane limieten te organiseren voor geïsoleerde WebAssembly-code, die mogelijk door een aanvaller kan worden gebruikt om de uitvoering van zijn code buiten de geïsoleerde WASI-omgeving te orkestreren.
Voor degenen die niet bekend zijn met Wasmtime, u moet weten dat dit een runtime is voor het uitvoeren van WebAssembly-applicaties met WASI-extensies (WebAssembly System Interface) als normale zelfstandige applicaties.
Wasmtime is geschreven in Rust en het beveiligingslek is te wijten aan een logische fout in de definitie van routeringsregels van lineair geheugen in de Cranelift-codegenerator, die een tussenliggende weergave, onafhankelijk van hardware-architecturen, vertaalt naar uitvoerbare machinecode voor de x86_64-architectuur.
Met betrekking tot de gefixeerde kwetsbaarheid wordt vermeld dat met name effectieve 35-bits adressen werden berekend voor WebAssembly-toepassingen in plaats van de 33-bits adressen toegestaan in WebAssembly, waardoor de toegestane limiet voor het virtuele geheugen voor lees- en schrijfbewerkingen werd gewijzigd in 34 GB, terwijl de sandbox-omgevingsinstelling bescherming biedt voor 6 GB. vanaf het basisadres.
Cranelift, de codegenerator van Wasmtime, heeft een bug in x86_64-doelen waarbij de berekening van de adresmodus per ongeluk een 35-bits effectief adres berekent in plaats van het 33-bits effectieve adres dat is gedefinieerd door WebAssembly. Deze bug betekent dat, met de standaardconfiguratie voor het genereren van codes, een wasm-gestuurde laad-/opslagbewerking adressen kan lezen/schrijven tot 35 bits verwijderd van de basis van het lineaire geheugen.
Als gevolg hiervan het virtuele geheugenbereik van 6 tot 34 GB vanaf het basisadres kwam beschikbaar voor lezen en schrijven van WebAssembly-applicaties. Dit geheugen kan andere WebAssembly-omgevingen of WebAssembly-runtimecomponenten bevatten.
Bijvoorbeeld (i32.load (i32.shl (local.get 0) (i32.const 3))), wordt geladen vanaf WebAssembly-adres $local0 << 3. Wanneer vertaald naar Cranelift, wordt de berekening van $local0 << 3 een 32-bits waarde, nul-geëxpandeerd tot een 64-bits waarde, en vervolgens toegevoegd aan het basisadres van lineair geheugen. Cranelift zou een verklaring genereren van de vorm movl(%base, %local0, 8), %dst die %base + %local0 << 3 berekent.
De fout hier is echter dat de adresberekening plaatsvindt met 64-bits waarden, waarbij $local0 << 3 het adres moest afkappen tot een 32-bits waarde. Dit betekent dat %local0, dat tot 32 bits voor een adres kan gebruiken, 3 extra bits adresruimte krijgt om toegankelijk te zijn via movl .
Tenslotte zoals altijd wordt aanbevolen om het pakket bij te werken naar de nieuwste beschikbare versieHet is ook vermeldenswaard dat er verschillende mogelijke oplossingen zijn die kunnen worden gebruikt om dit probleem te verhelpen als de update niet mogelijk is.
Er wordt vermeld dat geen van deze oplossingen standaard is ingeschakeld en expliciete configuratie vereist:
- Als het niet mogelijk is om de versie van Wasmtime bij te werken, wordt de optie "Config::static_memory_maximum_size(0)" genoemd om verplichte afzonderlijke grenscontroles op elke lineaire geheugentoegang in te schakelen als tijdelijke oplossing om de fout te blokkeren (resulteert in een aanzienlijke verslechtering van de prestaties ).
- Een andere optie is om de instelling "Config::static_memory_guard_size(1 < 36)" te gebruiken om het aantal bewakingspagina's (Bewakingspagina, throw-uitzondering bij toegang) in het problematische virtuele geheugenbereik te vergroten (leidt tot het reserveren van een grote hoeveelheid virtuele geheugen en beperking van het aantal gelijktijdige WebAssembly-applicaties).
- Als het mogelijk is om een niet-x86_64-host te gebruiken, wordt deze fout ook verholpen. Deze bug heeft geen invloed op de AArch64-backend van bijvoorbeeld Wasmtime of Cranelift.
Eindelijk Als u er meer over wilt weten, u kunt de details inchecken de volgende link.