{"code":"NK7YTF","title":"Escaping a misleading \"sandbox\": breaking the WebAssembly-JavaScript barrier","speakers":["7JZXGX"],"submission_type":2,"track":2,"tags":[],"state":"confirmed","abstract":"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?","description":"(Also released as write-up in Phrack #72)\r\n\r\nWhen talking about WebAssembly, the word \"sandbox\" comes up often: modules are isolated from eachother, and from the host runtime.\r\nHence, 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.\r\n\r\n... is what I thought.\r\n\r\nIn 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.","duration":50,"slot_count":1,"content_locale":"en","do_not_record":false,"image":null,"resources":[],"slots":[13288],"answers":[]}