Jika dieksploitasi, kelemahan ini boleh membenarkan penyerang mendapat akses tanpa kebenaran kepada maklumat sensitif atau secara amnya menyebabkan masalah
Beberapa hari lalu lKemas kini pembetulan Wasmtime 6.0.1, 5.0.1 dan 4.0.1 dikeluarkan bahawa mereka dapat memperbaiki kelemahan (telah dikatalogkan di bawah CVE-2023-26489) yang dinilai kritikal.
Kerentanan membolehkan untuk mengatur penulisan data dalam kawasan memori di luar had yang dibenarkan untuk kod WebAssembly terpencil, yang berpotensi digunakan oleh penyerang untuk mengatur pelaksanaan kod mereka di luar persekitaran WASI terpencil.
Bagi mereka yang tidak biasa dengan Wasmtime, anda harus tahu bahawa ini adalah masa jalan untuk menjalankan aplikasi WebAssembly dengan sambungan WASI (WebAssembly System Interface) sebagai aplikasi kendiri biasa.
Wasmtime ditulis dalam Rust dan kelemahan adalah disebabkan oleh ralat logik dalam definisi peraturan penghalaan memori linear dalam penjana kod Cranelift, yang menterjemahkan perwakilan perantaraan bebas daripada seni bina perkakasan kepada kod mesin boleh laku untuk seni bina x86_64.
Mengenai kelemahan tetap, disebutkan bahawa khususnya, alamat 35-bit berkesan telah dikira untuk aplikasi WebAssembly bukannya alamat 33-bit yang dibenarkan dalam WebAssembly, yang menukar had memori maya yang dibenarkan untuk operasi baca dan tulis kepada 34 GB, manakala tetapan persekitaran kotak pasir menyediakan perlindungan untuk 6 GB. daripada alamat pangkalan.
Penjana kod Wasmtime, Cranelift, mempunyai pepijat dalam sasaran x86_64 di mana pengiraan mod alamat akan tersilap mengira alamat berkesan 35-bit dan bukannya alamat berkesan 33-bit yang ditakrifkan oleh WebAssembly. Pepijat ini bermakna, dengan konfigurasi penjanaan kod lalai, operasi beban/stor yang dikawal wasm boleh membaca/menulis alamat sehingga 35 bit dari pangkalan memori linear.
Akibatnya, julat memori maya dari 6 hingga 34 GB dari alamat asas tersedia untuk membaca dan menulis daripada aplikasi WebAssembly. Memori ini boleh memegang persekitaran WebAssembly lain atau komponen masa jalan WebAssembly.
Contohnya (i32.load (i32.shl (local.get 0) (i32.const 3))), dimuatkan daripada alamat WebAssembly $local0 << 3. Apabila diterjemahkan kepada Cranelift, pengiraan $local0 << 3 kepada nilai 32-bit, adalah sifar dikembangkan kepada nilai 64-bit, dan kemudian ditambah pada alamat asas memori linear. Cranelift akan menjana pernyataan bentuk movl(%base, %local0, 8), %dst yang mengira %base + %local0 << 3.
Ralat di sini, bagaimanapun, ialah pengiraan alamat berlaku dengan nilai 64-bit, di mana $local0 << 3 sepatutnya memotong alamat kepada nilai 32-bit. Ini bermakna %local0, yang boleh menggunakan sehingga 32 bit untuk alamat, mendapat tambahan 3 bit ruang alamat untuk boleh diakses melalui movl .
Akhirnya, seperti biasa adalah disyorkan untuk mengemas kini pakej kepada versi terkini yang tersediaPerlu juga dinyatakan bahawa terdapat beberapa kemungkinan penyelesaian yang boleh digunakan untuk mengurangkan masalah ini jika kemas kini tidak dapat dilakukan.
Disebutkan bahawa tiada penyelesaian ini dihidupkan secara lalai dan memerlukan konfigurasi eksplisit:
- Jika tidak mungkin untuk mengemas kini versi Wasmtime, pilihan "Config::static_memory_maximum_size(0)" disebut untuk membolehkan semakan sempadan berasingan mandatori pada sebarang akses memori linear sebagai penyelesaian untuk menyekat ralat (mengakibatkan kemerosotan prestasi yang ketara. ).
- Pilihan lain ialah menggunakan tetapan "Config::static_memory_guard_size(1 < 36)" untuk menambah bilangan halaman pengawal (Halaman Pengawal, pengecualian buang apabila diakses) yang terletak dalam julat memori maya yang bermasalah (membawa kepada menempah sejumlah besar maya memori dan mengehadkan bilangan aplikasi WebAssembly serentak).
- Jika boleh menggunakan hos bukan x86_64, itu juga akan membetulkan ralat ini. Pepijat ini tidak menjejaskan bahagian belakang AArch64 Wasmtime atau Cranelift, contohnya.
Akhirnya Sekiranya anda berminat untuk mengetahui lebih lanjut mengenainya, anda boleh menyemak butirannya di pautan berikut.