| # Web Assembly Security in Chromium |
| |
| TL;DR |
| From Chrome's threat model perspective we generally consider WASM and JavaScript |
| to be in the same risk category - potentially actively malicious. We will run |
| arbitrary WASM from the web without any indication of trust and rely on V8's |
| security model as well as our renderer sandbox to contain potentially malicious |
| behavior. Any outputs from such WASM and JavaScript need to be regarded as |
| untrusted by the rest of the browser code. |
| |
| ## Background |
| |
| As the web continues to evolve, the greater ecosystem brings with it new and |
| exciting capabilities. From ajax to shadow DOM, Blink, Chrome, and others |
| continue to push the web forward. |
| |
| One such capability is to run native code. The latest standard to do so on the |
| web is via [web assembly](https://webassembly.org/). |
| |
| When it comes to security, web assembly prompts a series of concerns centered |
| around our understanding of the insecurity of native code. Some of these |
| specific issues are addressed below. Native code suffers from a |
| variety of memory vulnerabilities which can result in remote code execution |
| (RCE). By some measures, 60-70% of security bugs fall into this category. |
| |
| Web assembly baked in memory safety measures to prevent RCE. In particular, |
| wasm’s memory model is to give the page a single, continuous block of |
| memory. This memory is isolated from the program’s binary instructions. [Learn |
| more](https://webassembly.org/docs/security/). |
| |
| ## CPU bugs, side channel attacks |
| |
| WASM is not materially different from JavaScript in this regard and both may be |
| vulnerable. |
| |
| ## Malicious Input |
| |
| WASM is not materially different from JavaScript in this regard and both may be |
| vulnerable. |
