CVE-2021-39219 in Wasmtime
Summary
by MITRE • 09/18/2021
Wasmtime is an open source runtime for WebAssembly & WASI. Wasmtime before version 0.30.0 is affected by a type confusion vulnerability. As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type. Triggering this bug requires using at least two `Engine` values in an embedding and then additionally using two different values with a `Linker` (one at the creation time of the `Linker` and another when instantiating a module with the `Linker`). It's expected that usage of more-than-one `Engine` in an embedding is relatively rare since an `Engine` is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small. The fix implemented is to change this behavior to `panic!()` in Rust instead of silently allowing it. Using different `Engine` instances with a `Linker` is a programmer bug that `wasmtime` catches at runtime. This bug has been patched and users should upgrade to Wasmtime version 0.30.0. If you cannot upgrade Wasmtime and are using more than one `Engine` in your embedding it's recommended to instead use only one `Engine` for the entire program if possible. An `Engine` is designed to be a globally shared resource that is suitable to have only one for the lifetime of an entire process. If using multiple `Engine`s is required then code should be audited to ensure that `Linker` is only used with one `Engine`.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/22/2021
The vulnerability CVE-2021-39219 affects Wasmtime, an open source runtime for WebAssembly and WASI, specifically in versions prior to 0.30.0. This issue represents a type confusion vulnerability that arises from improper handling of cross-Engine usage within the safe API of Wasmtime's Linker::func_* functions. The flaw occurs when a Linker is created using one Engine instance and subsequently used to instantiate a module into a Store created with a different Engine instance. This scenario violates Wasmtime's design principle that Engine instances should serve as globally shared resources, intended for use throughout an entire process lifetime rather than multiple concurrent instances within a single embedding. The vulnerability manifests through the unsafe interaction between different Engine instances, potentially leading to function pointer type confusion that allows safe API calls to execute with incorrect function signatures.
The technical flaw stems from Wasmtime's API design where the safe functions Linker::func_* were not properly enforcing Engine consistency checks. When an Engine is used to create a Linker, the system stores metadata about function signatures and types that are specific to that Engine's context. However, when the same Linker is later used with a Store created from a different Engine, the type information becomes mismatched, creating a type confusion scenario. This type confusion can result in memory safety violations and potentially arbitrary code execution, as function pointers may be interpreted with incorrect types during invocation. The vulnerability is classified as a type confusion issue under CWE-121 and represents a memory safety problem in Rust code that violates the principle of safe memory management. The implementation flaw exists in the safe API layer where the runtime should have enforced consistency checks between Engine instances but failed to do so.
The operational impact of this vulnerability is significant despite the relatively rare usage pattern of multiple Engines in typical embeddings. The vulnerability requires a specific sequence of operations involving at least two Engine values and two different values with a Linker, making it less likely to occur in normal usage but still dangerous when it does occur. The vulnerability can result in memory unsafety issues that may lead to crashes, data corruption, or potentially more severe consequences depending on the embedding environment. Attackers who can control the embedding environment and manipulate Engine usage patterns could potentially exploit this to execute arbitrary code within the Wasmtime runtime. The vulnerability has been classified under the ATT&CK technique T1059.007 for Command and Scripting Interpreter: PowerShell, as it involves execution of potentially malicious code through function pointer manipulation. The impact is particularly concerning in environments where Wasmtime is used for sandboxed execution of untrusted code, as it could allow privilege escalation or information disclosure.
The fix implemented in Wasmtime version 0.30.0 addresses this vulnerability by changing the behavior from silent acceptance to explicit panic!() in Rust, effectively making the incorrect usage pattern a runtime error rather than allowing it to proceed silently. This approach aligns with the principle of fail-fast security mechanisms that prevent dangerous conditions from being silently ignored. The recommended mitigation strategy involves ensuring that only a single Engine instance is used throughout the entire program lifecycle, as Engines are designed to be globally shared resources. Users who cannot immediately upgrade should audit their code to ensure Linker usage is consistent with a single Engine instance, as this prevents the cross-Engine type confusion from occurring. The vulnerability highlights the importance of proper resource management in safe Rust code, where even safe APIs must properly validate their inputs to prevent memory safety violations. Organizations should implement code review processes to identify potential cross-Engine usage patterns and ensure compliance with Wasmtime's intended usage patterns to prevent exploitation of this vulnerability.