Escaping a misleading "sandbox": breaking the WebAssembly-JavaScript barrier (WHY2025)

When embedded into JavaScript, WebAssembly modules can be "sandboxed" by defining a limited set of _imports_. It turns out that an obscure "feature" allows us to craft an exploit which bypasses this barrier, enabling us to run arbitrary JavaScript code (pop an alert) from within a malicious WASM module. All within spec... by accident? (Also released as write-up in Phrack #72) When talking about WebAssembly, the word "sandbox" comes up often: modules are isolated from eachother, and from the host runtime. Hence, it is perfectly safe to run untrusted WASM modules (e.g. plugins) in a web-app: the module's interfaces can be limited, making it such that any malicious code has no way of escaping. ... is what I thought. In this talk I will show how a sneaky specification detail allows us to program a JavaScript version of a _weird machine_, to eventually escape from WebAssembly into running arbitrary JavaScript code. This trick is fully in-spec and requires no actual browser exploitation (we don't break _that_ sandbox). Hence, this talk should be accessible for anyone with a basic JavaScript understanding. No WebAssembly experience is required: I will cover everything required to understand the exploit. Licensed to the public under https://creativecommons.org/licenses/by/4.0/ about this event: https://program.why2025.org/why2025/talk/NK7YTF/