1# Security 2 3One of WebAssembly (and Wasmtime's) main goals is to execute untrusted code in 4a safe manner inside of a sandbox. WebAssembly is inherently sandboxed by design 5(must import all functionality, etc). This document is intended to cover the 6various sandboxing implementation strategies that Wasmtime has as they are 7developed. This has also been documented in a [historical blog post] too. 8 9[historical blog post]: https://bytecodealliance.org/articles/security-and-correctness-in-wasmtime 10 11At this time Wasmtime implements what's necessary for the WebAssembly 12specification, for example memory isolation between instances. Additionally the 13safe Rust API is intended to mitigate accidental bugs in hosts. 14 15Different sandboxing implementation techniques will also come with different 16tradeoffs in terms of performance and feature limitations, and Wasmtime plans to 17offer users choices of which tradeoffs they want to make. 18 19## WebAssembly Core 20 21The core WebAssembly spec has several features which create a unique sandboxed 22environment: 23 24 - The callstack is inaccessible. Unlike most native execution environments, 25 return addresses from calls and spilled registers are not stored in memory 26 accessible to applications. They are stored in memory that only the 27 implementation has access to, which makes traditional stack-smashing attacks 28 targeting return addresses impossible. 29 30 - Pointers, in source languages which have them, are compiled to offsets 31 into linear memory, so implementations details such as virtual addresses 32 are hidden from applications. And all accesses within linear memory are 33 checked to ensure they stay in bounds. 34 35 - All control transfers—direct and indirect branches, as well as direct and 36 indirect calls—are to known and type-checked destinations, so it's not 37 possible to accidentally call into the middle of a function or branch 38 outside of a function. 39 40 - All interaction with the outside world is done through imports and exports. 41 There is no raw access to system calls or other forms of I/O; the only 42 thing a WebAssembly instance can do is what is available through interfaces 43 it has been explicitly linked with. 44 45 - There is no undefined behavior. Even where the WebAssembly spec permits 46 multiple possible behaviors, it doesn't permit arbitrary behavior. 47 48## Defense-in-depth 49 50While WebAssembly is designed to be sandboxed bugs or issues inevitably arise so 51Wasmtime also implements a number of mitigations which are not required for 52correct execution of WebAssembly but can help mitigate issues if bugs are found: 53 54* Linear memories by default are preceded with a 2GB guard region. WebAssembly 55 has no means of ever accessing this memory but this can protect against 56 accidental sign-extension bugs in Cranelift where if an offset is accidentally 57 interpreted as a signed 32-bit offset instead of an unsigned offset it could 58 access memory before the addressable memory for WebAssembly. 59 60* Wasmtime uses explicit checks to determine if a WebAssembly function should be 61 considered to stack overflow, but it still uses guard pages on all native 62 thread stacks. These guard pages are never intended to be hit and will abort 63 the program if they're hit. Hitting a guard page within WebAssembly indicates 64 a bug in host configuration or a bug in Cranelift itself. 65 66* Where it can Wasmtime will zero memory used by a WebAssembly instance after 67 it's finished. This is not necessary unless the memory is actually reused for 68 instantiation elsewhere but this is done to prevent accidental leakage of 69 information between instances in the face of other bugs. This applies to 70 linear memories, tables, and the memory used to store instance information 71 itself. 72 73* The choice of implementation language, Rust, for Wasmtime is also a 74 defense in protecting the authors for Wasmtime from themselves in addition to 75 protecting embedders from themselves. Rust helps catch mistakes when writing 76 Wasmtime itself at compile time. Rust additionally enables Wasmtime developers 77 to create an API that means that embedders can't get it wrong. For example 78 it's guaranteed that Wasmtime won't segfault when using its public API, 79 empowering embedders with confidence that even if the embedding has bugs all 80 of the security guarantees of WebAssembly are still upheld. 81 82* Wasmtime is in the [process of implementing control-flow-integrity 83 mechanisms][cfi-rfc] to leverage hardware state for further guaranteeing that 84 WebAssembly stays within its sandbox. In the event of a bug in Cranelift this 85 can help mitigate the impact of where control flow can go to. 86 87[cfi-rfc]: https://github.com/bytecodealliance/rfcs/blob/main/accepted/cfi-improvements-with-pauth-and-bti.md 88 89## Filesystem Access 90 91Wasmtime implements the WASI APIs for filesystem access, which follow a 92capability-based security model, which ensures that applications can only 93access files and directories they've been given access to. WASI's security 94model keeps users safe today, and also helps us prepare for shared-nothing 95linking and nanoprocesses in the future. 96 97Wasmtime developers are intimately engaged with the WASI standards process, 98libraries, and tooling development, all along the way too. 99 100## Terminal Output 101 102If untrusted code is allowed to print text which is displayed to a terminal, it may 103emit ANSI-style escape sequences and other control sequences which, depending on 104the terminal the user is using and how it is configured, can have side effects 105including writing to files, executing commands, injecting text into the stream 106as if the user had typed it, or reading the output of previous commands. ANSI-style 107escape sequences can also confuse or mislead users, making other vulnerabilities 108easier to exploit. 109 110Our first priority is to protect users, so Wasmtime now filters writes to output 111streams when they are connected to a terminal to translate escape sequences into 112inert replacement sequences. 113 114Some applications need ANSI-style escape sequences, such as terminal-based 115editors and programs that use colors, so we are also developing a proposal for 116the WASI Subgroup for safe and portable ANSI-style escape sequence support, which 117we hope to post more about soon. 118 119## Spectre 120 121Wasmtime implements a few forms of basic spectre mitigations at this time: 122 123* Bounds checks when accessing entries in a function table (e.g. the 124 `call_indirect` instruction) are mitigated. 125 126* The `br_table` instruction is mitigated to ensure that speculation goes to a 127 deterministic location. 128 129* Wasmtime's default configuration for linear memory means that bounds checks 130 will not be present for memory accesses due to the reliance on page faults to 131 instead detect out-of-bounds accesses. When Wasmtime is configured with 132 "dynamic" memories, however, Cranelift will insert spectre mitigation for the 133 bounds checks performed for all memory accesses. 134 135Mitigating Spectre continues to be a subject of ongoing research, and Wasmtime 136will likely grow more mitigations in the future as well. 137 138Note that on aarch64 the `csdb` instruction is disabled by default due to its 139significant performance penalty, but this can be additionally enabled through 140the `use_csdb` Cranelift setting. 141