Using WebAssembly to run, extend, and secure your application!

### Overview In this presentation, Niels Tanis, a security researcher at Veracode with a background in .NET development and ethical hacking, explores how WebAssembly (Wasm) and the WebAssembly System Interface (WASI) can be leveraged to run, extend, and secure software applications. While originally designed to deliver high-performance, portable code inside web browsers, WebAssembly has evolved into a general-purpose, capability-based sandboxing technology capable of running on hosts and in confidential cloud computing environments.

### Key Topics - **WebAssembly Design and Core Security Principles:** Wasm operates as a portable compilation target and binary instruction format for a stack-based virtual machine. Key security foundations include strictly isolated linear memory (modules cannot read or write outside their assigned array of bytes) and control flow integrity (CFI), which maps valid execution branches at compile time and triggers runtime traps if unexpected jumps occur. - **Real-World Sandboxing (RLBox):** The speaker highlights Firefox's RLBox project, which isolates untrusted third-party C libraries (such as font renderers) by compiling them to Wasm, translating them back to C, and enforcing explicit taint tracking and validation on all data crossing the boundary. - **WASI and Host Runtime Sandboxing:** WASI abstracts OS-level calls into an engine-independent, capability-oriented interface. Using runtimes like Wasmtime, hosts can enforce secure defaults—denying file system, network socket, and resource access unless explicitly granted through pre-opened directories or mapped paths. - **Extending Applications with Resource Limits:** Host applications (demonstrated in .NET, Python, and Rust) can embed Wasm runtimes to execute untrusted plugins. Hosts can configure strict memory constraints and execution limits using Wasmtime's "fuel" metering system, which halts execution with a trap if compute consumption exceeds predefined bounds. - **Confidential Computing and the Component Model:** Wasm modules are entering trusted execution environments (TEEs) through projects like Enarx (built on Wasmtime) and Microsoft's Project Hyperlight. The emerging WebAssembly Component Model and "nano-processes" offer fine-grained dependency isolation, allowing developers to wrap third-party dependencies in declarative sandboxes with virtualized interfaces.

### Technical Details Tanis demonstrates several live technical workflows: - Running a .NET console application natively on an ARM64 macOS host versus executing inside a WASI-compliant runtime, showing that unauthorized attempts to read `/etc/hosts` fail immediately with runtime errors unless the directory is explicitly permitted. - Executing Python within a WASI runtime (`python.wasm`) via Wasmtime, requiring explicit pre-opened directory flags to allow file system access. - Compiling a Rust file-copying utility into Wasm and embedding it within a .NET host application via the `Wasmtime` package. The demo illustrates how the host must configure engines, linkers, stores, and redirected standard I/O, as well as manually specify allowed directories using `with_preopened_dir`. - Enabling Wasmtime's fuel consumption measurement: executing a file copy consumed roughly 35,000 fuel ticks, whereas capping the fuel limit to 500 caused the runtime to trap immediately due to fuel exhaustion.

### Takeaways WebAssembly provides robust, low-overhead isolation compared to heavy multi-process architectures or traditional containerization. However, Tanis emphasizes that overall security depends heavily on the correctness of the underlying Wasm runtime implementation. Initiatives by the Bytecode Alliance—such as writing Wasmtime in Rust with minimal unsafe code, enforcing continuous fuzzing, and using community dependency vetting via `cargo-vet`—aim to ensure robust runtime integrity as WASI Preview 2 and the Component Model mature.