{"id":107183,"date":"2023-03-10T18:48:11","date_gmt":"2023-03-10T16:48:11","guid":{"rendered":"https:\/\/prohoster.info\/?p=107183"},"modified":"2023-03-13T12:06:39","modified_gmt":"2023-03-13T10:06:39","slug":"kriticheskaya-uyazvimost-v-wasmtime-runtime-dlya-webassembly-prilozhenij","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/kriticheskaya-uyazvimost-v-wasmtime-runtime-dlya-webassembly-prilozhenij","title":{"rendered":"A critical vulnerability in Wasmtime, the runtime for WebAssembly applications","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
In the corrective updates of Wasmtime 6.0.1, 5.0.1, and 4.0.1, a vulnerability (CVE-2023-26489) has been fixed, which has been assigned a critical risk level. This vulnerability allows unauthorized data to be written in memory areas outside the boundaries permitted for isolated WebAssembly code, which could potentially be exploited by an attacker to execute their code outside the WASI isolated environment. <\/p>\n
Wasmtime is a runtime for executing WebAssembly applications with WASI (WebAssembly System Interface) extensions, functioning like ordinary isolated applications. The toolkit is written in Rust, and the vulnerability was caused by a logical error in determining the memory linear addressing rules in the Cranelift code generator, which translates architecture-independent intermediate representations into executable machine code for the x86_64 architecture. <\/p>\n
Specifically, effective 35-bit addresses were calculated for WebAssembly applications instead of the 33-bit addresses allowed in WebAssembly, shifting the boundary of permissible reading and writing operations in virtual memory to 34 GB, while the sandbox environment settings provide protection for 6 GB from the base address. As a result, the range of virtual memory from 6 to 34 GB from the base address became accessible for reading and writing by WebAssembly applications. This memory can contain other WebAssembly environments or components of the WebAssembly runtime. <\/p>\n
If updating the Wasmtime version is not possible, a workaround for blocking the error involves specifying the option 'Config::static_memory_maximum_size(0)' to enable mandatory separate boundary checks for any access to linear memory (which leads to a significant decrease in performance). Another option is to use the setting 'Config::static_memory_guard_size(1 < 36)' to increase the number of guard pages (Guard Page, an exception is generated upon access) placed in the problematic range of virtual memory (which results in reserving a large volume of virtual memory and limiting the number of WebAssembly applications that can run simultaneously). \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"