Jos näitä puutteita hyödynnetään, hyökkääjät voivat päästä luvattomasti arkaluontoisiin tietoihin tai aiheuttaa yleensä ongelmia
Muutama päivä sitten lWasmtime 6.0.1, 5.0.1 ja 4.0.1 korjaavat päivitykset julkaistu että he saavat korjata haavoittuvuuden (jo luetteloitu nimellä CVE-2023-26489), joka arvioitiin kriittiseksi.
Haavoittuvuus mahdollistaa tietojen kirjoittamisen järjestämisen sallittujen rajojen ulkopuolella olevalle muistialueelle erilliselle WebAssembly-koodille, jota hyökkääjä voi mahdollisesti käyttää ohjaamaan koodinsa suorittamista eristetyn WASI-ympäristön ulkopuolella.
Niiden, jotka eivät tunne Wasmtimea, sinun tulee tietää, että tämä on ajonaika WebAssembly-sovellusten suorittamiseen WASI-laajennuksilla (WebAssembly System Interface) normaaleina itsenäisinä sovelluksina.
Wasmtime on kirjoitettu kielellä Rust and haavoittuvuus johtuu loogisesta virheestä reitityssääntöjen määrittelyssä lineaarista muistia Cranelift-koodigeneraattorissa, joka muuntaa laitteistoarkkitehtuureista riippumattoman väliesityksen suoritettavaksi konekoodiksi x86_64-arkkitehtuurille.
Korjatun haavoittuvuuden osalta mainitaan, että erityisesti tehokkaat 35-bittiset osoitteet laskettiin WebAssembly-sovelluksiin WebAssemblyssa sallittujen 33-bittisten osoitteiden sijaan, joka muutti luku- ja kirjoitustoimintojen virtuaalisen muistin rajan 34 Gt:ksi, kun taas hiekkalaatikkoympäristöasetus tarjoaa suojan 6 Gt:lle. perusosoitteesta.
Wasmtimen koodigeneraattorissa, Craneliftissä, on bugi x86_64-kohteissa, joissa osoitetilan laskentatapa laskee virheellisesti 35-bittisen tehokkaan osoitteen WebAssemblyn määrittämän 33-bittisen osoitteen sijaan. Tämä virhe tarkoittaa, että oletuskoodin luontikonfiguraatiolla wasm-ohjattu lataus/tallennustoiminto voisi lukea/kirjoittaa osoitteita jopa 35 bitin päässä lineaarisen muistin pohjasta.
Tämän seurauksena virtuaalimuistialue 6 - 34 Gt perusosoitteesta tuli saataville lukemista ja kirjoittamista varten WebAssembly-sovelluksista. Tämä muisti voi sisältää muita WebAssembly-ympäristöjä tai WebAssembly-ajonaikaisia komponentteja.
Esimerkiksi (i32.load (i32.shl (local.get 0) (i32.const 3))), ladataan WebAssembly-osoitteesta $local0 << 3. Kun käännetään Craneliftiksi, $local0 << 3 32-bittinen arvo, laajennetaan nolla 64-bittiseksi arvoksi ja lisätään sitten lineaarisen muistin perusosoitteeseen. Cranelift luo lauseen muodossa movl(%base, %local0, 8), %dst, joka laskee %base + %local0 << 3.
Virhe tässä on kuitenkin se, että osoitteen laskenta tapahtuu 64-bittisillä arvoilla, joissa $local0 << 3 piti katkaista osoitteen 32-bittiseksi arvoksi. Tämä tarkoittaa, että %local0, joka voi käyttää osoitteeseen jopa 32 bittiä, saa 3 bittiä lisää osoiteavaruutta, jotta sitä voidaan käyttää movl:n kautta.
Lopuksi, kuten aina, on suositeltavaa päivittää paketti uusimpaan saatavilla olevaan versioonOn myös syytä mainita, että on olemassa useita mahdollisia ratkaisuja, joilla tätä ongelmaa voidaan lieventää, jos päivitys ei ole mahdollista.
Mainitaan, että mikään näistä ratkaisuista ei ole oletuksena käytössä ja vaatii nimenomaisen määrityksen:
- Jos Wasmtime-version päivittäminen ei ole mahdollista, mainitaan vaihtoehto "Config::static_memory_maximum_size(0)", joka mahdollistaa pakollisen erillisen rajatarkistuksen missä tahansa lineaarisessa muistinkäytössä kiertotapana virheen estämiseksi (johtaa merkittävään suorituskyvyn heikkenemiseen). ).
- Toinen vaihtoehto on käyttää "Config::static_memory_guard_size(1 < 36)" -asetusta lisätäksesi ongelmallisella virtuaalimuistialueella olevien suojasivujen määrää (suojasivu, heittää poikkeus käytettäessä) (johtii suuren määrän virtuaalimuistin varaamiseen muisti ja samanaikaisten WebAssembly-sovellusten määrän rajoittaminen).
- Jos on mahdollista käyttää muuta kuin x86_64-isäntää, se myös korjaa tämän virheen. Tämä bugi ei vaikuta esimerkiksi Wasmtimen tai Craneliftin AArch64-taustaohjelmaan.
Vihdoin Jos haluat tietää enemmän siitä, voit tarkistaa yksityiskohdat seuraava linkki.