<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Wasmtime - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/wasmtime/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Tue, 02 Jan 2024 12:00:00 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/wasmtime/feed.xml" rel="self" type="application/rss+xml"/><item><title>Wasmtime Cranelift AArch64 Sandbox Escape Vulnerability</title><link>https://feed.craftedsignal.io/briefs/2024-01-wasmtime-sandbox-escape/</link><pubDate>Tue, 02 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-wasmtime-sandbox-escape/</guid><description>A critical sandbox escape vulnerability exists in Wasmtime's Cranelift compilation backend on aarch64, allowing guest WebAssembly modules to bypass bounds checks and achieve arbitrary read/write access to host memory under specific configuration conditions.</description><content:encoded><![CDATA[<p>A critical vulnerability has been identified in Wasmtime's Cranelift compilation backend specifically affecting aarch64 architectures. This flaw stems from a miscompilation of heap accesses, leading to incorrect address calculations within guest WebAssembly modules. This allows a malicious guest module to bypass memory bounds checks and gain unauthorized read/write access to the host system's memory. The vulnerability is present in Wasmtime versions prior to 36.0.7, between 37.0.0 and 42.0.2, and version 43.0.0. Successful exploitation requires specific conditions: 64-bit WebAssembly linear memories must be in use (<code>Config::wasm_memory64</code> enabled, which is the default), and either Spectre mitigations or signals-based-traps must be disabled. This vulnerability allows a sandbox escape enabling attackers to compromise the host system from within the WebAssembly runtime.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>A malicious WebAssembly module is loaded into Wasmtime.</li>
<li>The module is compiled using the Cranelift backend on an aarch64 architecture.</li>
<li>The module contains a heap access operation of the form <code>load(iadd(base, ishl(index, amt)))</code> where <code>amt</code> is a constant.</li>
<li>Cranelift miscompiles this load instruction due to an incorrect mask applied to the <code>amt</code> value during instruction selection.</li>
<li>The WebAssembly module performs a bounds check on the intended memory address.</li>
<li>Due to the miscompilation, the address used for the actual load operation is different from the address used in the bounds check, effectively bypassing the check.</li>
<li>The module performs an arbitrary read or write operation to host memory outside of the WebAssembly sandbox.</li>
<li>The attacker gains control or extracts sensitive information from the host system.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation of this vulnerability allows a malicious WebAssembly module to escape the Wasmtime sandbox. This grants the attacker the ability to read and write arbitrary memory locations on the host system, leading to potential data exfiltration, privilege escalation, or complete system compromise. The vulnerability affects applications and systems that rely on Wasmtime for sandboxed execution of WebAssembly code on aarch64 architectures, potentially impacting a wide range of services and infrastructure.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Upgrade to Wasmtime version 36.0.7, 42.0.2, or 43.0.1 or later to patch the vulnerability as described in the <a href="https://github.com/advisories/GHSA-jhxm-h53p-jm7w">Wasmtime advisory</a>.</li>
<li>If upgrading is not immediately feasible, ensure that Spectre mitigations are enabled in your Wasmtime configuration as a workaround.</li>
<li>As an alternative workaround, disable <code>Config::wasm_memory64</code> if your application does not require 64-bit WebAssembly linear memories.</li>
<li>Monitor systems running Wasmtime on aarch64 architectures for anomalous memory access patterns that could indicate exploitation of this vulnerability.</li>
</ul>
]]></content:encoded><category domain="severity">critical</category><category domain="type">advisory</category><category>wasmtime</category><category>cranelift</category><category>aarch64</category><category>sandbox-escape</category><category>memory-corruption</category></item></channel></rss>