Uploaded October 2019 | Updated September 2026, 5 days ago
WebAssembly (WASM) is a new technology being developed by the major browser vendors through the W3C. A direct descendent of NaCl and Asm.js, the idea is to allow web developers to run native (e.g. C/C++) code in a web page at near-native performance. WASM is already widely supported in the latest versions of all major browsers, and new use case examples are constantly popping up in the wild. Notable examples include 3D model rendering, interface design, visual data processing, and video games. Beyond providing significant performance benefits to developers, WebAssembly is also touted as being exceptionally secure. Developers claim that buffer overflows will be an impossibility, as any attempted access to out-of-bounds memory will be caught by a Javascript error. Their documentation claims that control flow integrity is enforced implicitly and that "common mitigations such as data execution prevention (DEP) and stack smashing protection (SSP) are not needed by WebAssembly programs." However, the documentation also outlines several possible vectors of attacks, including race conditions, code reuse attacks, and side channel attacks.
The goal of this talk is to provide a basic introduction to WebAssembly and examine the actual security risks that a developer may take on by using it. We will cover the low-level semantics of WebAssembly, including the Javascript API, the linear memory model, and the use of tables as function pointers. We will cover several examples demonstrating the theoretical security implications of WASM, such as linear memory being shared between modules and the passing of a Javascript 'Number' to a WASM function that expects a signed integer. We will also cover Emscripten, which is currently the most popular WebAssembly compiler toolchain. Our assessment of Emscripten will include its implementation of compiler-and-linker-level exploit mitigations as well as the internal hardening of its libc implementation, and how it's augmentation of WASM introduces new attack vectors and methods of exploitation. As part of this we will also provide practical examples of memory corruption exploits in the WASM environment that may lead to hijacking control flow or even executing arbitrary JavaScript within the context of the web page. Finally, we will provide a basic outline of best practices and security considerations for developers wishing to integrate WebAssembly into their product.
WebAssembly (WASM) is a new technology being developed by the major browser vendors through the W3C. A direct descendent of NaCl and Asm.js, the idea is to allow web developers to run native (e.g. C/C++) code in a web page at near-native performance. WASM is already widely supported in the latest versions of all major browsers, and new use case examples are constantly popping up in the wild. Notable examples include 3D model rendering, interface design, visual data processing, and video games. Beyond providing significant performance benefits to developers, WebAssembly is also touted as being exceptionally secure. Developers claim that buffer overflows will be an impossibility, as any attempted access to out-of-bounds memory will be caught by a Javascript error. Their documentation claims that control flow integrity is enforced implicitly and that "common mitigations such as data execution prevention (DEP) and stack smashing protection (SSP) are not needed by WebAssembly programs." However, the documentation also outlines several possible vectors of attacks, including race conditions, code reuse attacks, and side channel attacks.
The goal of this talk is to provide a basic introduction to WebAssembly and examine the actual security risks that a developer may take on by using it. We will cover the low-level semantics of WebAssembly, including the Javascript API, the linear memory model, and the use of tables as function pointers. We will cover several examples demonstrating the theoretical security implications of WASM, such as linear memory being shared between modules and the passing of a Javascript 'Number' to a WASM function that expects a signed integer. We will also cover Emscripten, which is currently the most popular WebAssembly compiler toolchain. Our assessment of Emscripten will include its implementation of compiler-and-linker-level exploit mitigations as well as the internal hardening of its libc implementation, and how it's augmentation of WASM introduces new attack vectors and methods of exploitation. As part of this we will also provide practical examples of memory corruption exploits in the WASM environment that may lead to hijacking control flow or even executing arbitrary JavaScript within the context of the web page. Finally, we will provide a basic outline of best practices and security considerations for developers wishing to integrate WebAssembly into their product.
