Listen to this Post
The vulnerability stems from Wasmtime’s allocation logic for WebAssembly tables. When the memory64 proposal is enabled (on by default), tables can have sizes in the 64-bit range, unlike the legacy 32-bit limit. The allocation routine performs checked arithmetic to compute required memory. An attacker can trigger an overflow by requesting a table with an extremely large size (e.g., near 2^64 entries). The checked arithmetic detects the overflow and calls `panic!()` in Rust, aborting the host process. This panic occurs during instantiation of a malicious WebAssembly module or component. The issue only affects the on‑demand instance allocator (Wasmtime’s default). The pooling allocator is immune because it enforces much smaller table size limits. A successful panic leads to a denial‑of‑service (DoS) of the host process. The overflow is exploitable without special privileges if untrusted WebAssembly code is executed. Patches were released in versions 36.0.8, 43.0.2, and 44.0.1. Workarounds include switching to the pooling allocator or disabling the memory64 proposal.
dailycve form:
Platform: Wasmtime
Version: before 36.0.8, 43.0.2, 44.0.1
Vulnerability: Table allocation overflow
Severity: Medium
date: Not disclosed
Prediction: Already patched (Dec 2024)
What Undercode Say:
Check Wasmtime version wasmtime --version Test for overflow (conceptual - requires malicious .wasm) wasmtime run --wasm-features memory64 exploit.wat Enable pooling allocator as workaround wasmtime run --pooling-allocator exploit.wat Disable memory64 proposal wasmtime run --wasm-features=-memory64 exploit.wat
Exploit:
Craft a WebAssembly module with a table section specifying an initial size near 2^64 (e.g., 0xFFFFFFFFFFFFFFFF). Instantiate the module using Wasmtime’s on-demand allocator. The checked arithmetic in `table.rs` overflows, triggering a panic and crashing the host.
Protection from this CVE:
Upgrade to Wasmtime 36.0.8, 43.0.2, 44.0.1 or later. If upgrade is impossible, switch to the pooling allocator (--pooling-allocator) or disable the memory64 proposal (--wasm-features=-memory64).
Impact:
Denial‑of‑service via host process panic. Affects any application that executes untrusted WebAssembly modules using Wasmtime’s default allocator with memory64 enabled. Does not impact the pooling allocator.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
