CVE-2023-26489: Bytecode Alliance Wasmtime Code Execution Vulnerability
Wasmtime is a Bytecode Alliance project that is a standalone wasm-only optimizing runtime for WebAssembly and WASI. It runs WebAssembly code outside of the Web and can be used both as a command-line utility or as a library embedded in a larger application.
Recently, Wasmtime has been found to have a security vulnerability that can allow a remote attacker to execute arbitrary code on the system. CVE-2023-26489, with a CVSS3 score of 9.9, is caused by an out-of-bounds read/write on x86_64. This bug means that a wasm-controlled load/store operation could read/write addresses up to 35 bits away from the base of linear memory. Due to this bug, a malicious module can read/write virtual memory within ~34G of linear memory away from the base of a wasm module’s linear memory. By sending a specially crafted request, an attacker could exploit this vulnerability to execute arbitrary code on the system.
The bug lies in Cranelift’s x86_64 backend where a WebAssembly address is left-shifted by a constant amount from 1 to 3, resulting in a 35-bit effective address instead of WebAssembly’s defined 33-bit effective address. The specific bug in Cranelift’s x86_64 backend is that a WebAssembly address computation happens with 64-bit values instead of truncating the $local0 << 3 computation to a 32-bit value.
Wasmtime versions 4.0.1, 5.0.1, and 6.0.1 have all been patched to no longer contain the erroneous lowering rules. However, there are several workarounds that embedders can use to mitigate the CVE-2023-26489 vulnerability if updating is not possible. These include using Config::static_memory_maximum_size(0) to force all accesses to linear memory to be explicitly bounds-checked, Config::static_memory_guard_size(1 << 36) to greatly increase the guard pages placed after linear memory, or using a non-x86_64 host if possible.
Affected embedders are recommended to analyze preexisting wasm modules to see if they’re affected by the incorrect codegen rules and possibly correlate that with an anomalous number of traps during historical execution to locate possibly suspicious modules. The Wasmtime team also suggests that embedders keep their Wasmtime runtimes updated to the latest version to stay protected from this vulnerability.
