## 2 Understanding WebAssembly
### The Security Model of WebAssembly  
Wasm incorporates a security model with two primary goals: (1) protecting users from potentially malicious or faulty modules, and (2) providing developers with effective tools and measures to create secure applications within the given constraints [17]. * **User Protection*
* Wasm modules operate within a secure sandbox environment that uses fault isolation techniques to separate them from the host runtime. This ensures the following:
* Applications run independently within the sandbox, and cannot escape without using appropriate APIs. * Deterministic execution is generally maintained, with limited exceptions. * Modules adhere to the security policies of their embedding. In web browsers, this includes restrictions imposed by the same-origin policy, while other platforms may have their own security models. * **Developer Support*
* Wasm's design focuses on supporting the development of secure programs by eliminating dangerous features from its execution semantics while remaining compatible with C/C++ code. * Modules must declare all accessible functions and associated types during load time, even when utilizing dynamic linking. This enables implicit control-flow integrity through structured control flow. Immutable compiled code and lack of runtime observability protect Wasm programs from control flow hijacking attacks. * Function calls within Wasm must specify valid target indices that correspond to entries in the function index space or table index space. * Indirect function calls undergo runtime type signature checks, ensuring that the selected function matches the expected signature. * The use of a protected call stack prevents buffer overflows in the module heap and ensures safe function returns. * Branches within functions must point to valid destinations within the same function. * Variables in C/C++ are represented using primitives in Wasm, depending on their scope. Local variables with fixed scope and global variables are stored as fixed-type values indexed by their respective indices. Local variables are initialized to zero and stored in the protected call stack, while global variables reside in the global index space and can be imported from external modules. Local variables with uncertain static scope are stored in a separate user-addressable stack in linear memory during compilation. Bounds checking is performed at the region level to prevent out-of-bounds accesses. Future enhancements may include support for multiple memory sections and more advanced memory operations. * Traps are used to immediately terminate execution and signal abnormal behavior. They are triggered by operations such as invalid index access, mismatched type signature in indirect function calls, exceeding the maximum size of the protected call stack, out-of-bounds linear memory access, or illegal arithmetic operations. * **Memory Safety** Wasm's execution semantics mitigate certain memory safety issues compared to traditional C/C++ programs. Local and global variables stored in the index space are protected from buffer overflows due to their fixed sizes and indexed addressing. Linear memory accesses are checked at the region level, preventing out-of-bounds access. However, control-flow integrity and the protected call stack prevent direct code injection attacks. Hence, mitigations such as data execution prevention and stack smashing protection are unnecessary for Wasm programs. However, certain types of bugs are not obviated by Wasm's semantics. Control flow hijacking attacks can manipulate module control flow using code reuse attacks against indirect calls. Nevertheless, common techniques such as return-oriented programming are not possible in Wasm due to enforced control-flow integrity. Additionally, race conditions, side channel attacks, and time of check to time of use vulnerabilities can occur. Future enhancements may provide additional protections such as code diversification, memory randomization, or bounded pointers.