GHSA-mghf-wjfp-p5xm: Critical severity rust/wasmtime vulnerability
Summary
When running with the Cranelift compiler backend on an aarch64 target, Wasmtime can compile a Wasm module with more than ~256k targets on one brtable instruction in a way that results in an incorrect conditional branch target. This conditional branch could then jump to arbitrary other code (at an user-controlled offset), leading to arbitrary sandbox escapes.
Impact
Any Wasmtime engine running on aarch64 with default settings can be forced to jump to arbitrary code by a user-controlled Wasm module. All versions of Wasmtime/Cranelift that support aarch64, since the initial release of that support in 2020 (before Wasmtime v1.0), are affected.
Patches
Wasmtime v36.0.19, v48.0.7, and v49.0.4 have been released which all fix this issue.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rust/wasmtimeto a version that resolves this vulnerability.Fixed in 49.0.4 - Upgrade
Upgrade
rust/wasmtimeto a version that resolves this vulnerability.Fixed in 48.0.7 - Upgrade
Upgrade
rust/wasmtimeto a version that resolves this vulnerability.Fixed in 36.0.19 - Upgrade
Upgrade
Wasmtime/Craneliftto a version that resolves this vulnerability.Fixed in 36.0.19 - Upgrade
Upgrade
Wasmtime/Craneliftto a version that resolves this vulnerability.Fixed in 48.0.7 - Upgrade
Upgrade
Wasmtime/Craneliftto a version that resolves this vulnerability.Fixed in 49.0.4
Event History
Frequently Asked Questions
Which deployments are exposed?
Wasmtime engines using the Cranelift backend on aarch64 are affected under default settings. The issue affects all Wasmtime/Cranelift versions with aarch64 support, including releases before Wasmtime v1.0.
What must an attacker provide to exploit this?
An attacker needs to supply a user-controlled Wasm module containing a br_table instruction with more than approximately 256,000 targets. Exploitation can cause a conditional branch to jump to arbitrary code at a user-controlled offset, enabling a sandbox escape.
Are default configurations affected?
Yes. An aarch64 Wasmtime engine running with default settings can be forced to jump to arbitrary code by a user-controlled Wasm module.
Which fixed releases are available?
The issue is fixed in Wasmtime v36.0.19, v48.0.7, and v49.0.4.