Two-Faces of WASM Security

JavaScript is the most popular language of the web. It is one of the fastest dynamic languages around; even though it is fast it still cannot compete with raw C/C++. WebAssembly or WASM, an evolution of asm.js, is a low level, portable binary format ...

JavaScript is the most popular language of the web. It is one of the fastest dynamic languages around; even though it is fast it still cannot compete with raw C/C++. WebAssembly or WASM, an evolution of asm.js, is a low level, portable binary format that aims to speed up apps on the order of 20x compared to JavaScript. Developers can compile their C/C++/Rust code to wasm modules which can be directly used in JavaScript code. Currently, WA is supported across all major browsers.
The security model of WASM is based on two concepts: protect users from malicious modules and provide developers primitives to build secure modules. For users, wasm modules in a browser are designed to be executed in a safe and sandboxed environment. And for developers primitives like type safety, control flow integrity, execution traps, and protected stacks ensure that the modules are safe against direction code injection attacks.
We have seen an increased interest in using WebAssembly for malicious purposes. Initially the use of wasm was seen in keyloggers, and tech support scams. Recently, we have seen increased use of web assembly by coin-mining scripts. These mining scripts have become extremely sophisticated and hard to detect. The sophistication of web assembly has caused havoc to web authors as well, the number of vulnerable modules has been constantly increasing.
In this talk, we present two sides of wasm 1) Increased sophisitication of wasm modules for malicious intent 2) Exploitation of vulnerable modules presenting an increased attack surface for web-authors