Trust to executed code in WASM

[gene-eu-zz]

Since the list of use-cases for WASM mentions encryption, I'd like to understand better the design considerations behind WASM code execution in regard to security. Are there any, or just current status-quo with JS is going to be dragged along?

The problem with browser encryption is not only the performance, but trust. Current code execution model in-browser does not allow to reliably trust results of executing cryptographic code, because it's easy to hijack/override calls to it by some other, hostile code running on the same page ("execution context"), either injected locally, via XSS, via MiTM or least-secure connection among all page resources.

An attacker could do anything, from simply bypassing cryptography to injecting code, which produces visually similar results, but with certain cryptographic caveats, which enables an attacker to break security guarantees given by cryptography and yet keep output looking 'encrypted'.

There, of course, is no silver bullet in trust to bytes in memory (even HSMs can be circumvented in certain cases), but at least having a roadmap to mitigate current obvious risks is necessary for WASM to provide extra security value compared to regular JS crypto.

Given the amount of thought given to quality of runtime and execution, it seems that this is just not touched yet, or touched somewhere in some discussions I can't find?

[jfbastien]

WebAssembly doesn't have any APIs on its own. It interacts with web pages solely through JavaScript. It therefore has the same trust surface area as JavaScript in that respect.

[jayphelps]

@gene-eu for clarity, wasm code cannot modify itself (as currently spec'd)--unlike JavaScript. You can't monkey patch functions, or inject dynamic code with wasm alone. (no "eval" equivalent and dynamic invocation only via read-only function table, no executable memory) Since wasm currently requires JavaScript to bootstrap itself and do anything meaningful like IO, JavaScript is still the weak link. There's been some discussion around how loading wasm modules without JavaScript might work in #982, #972, prolly others but without direct WebIDL bindings to do IO you'd still need JavaScript as an intermediary.

In some hypothetical distant future where wasm could power a web app without a single line of JavaScript, combined with Subresource Integrity I feel like you'd have pretty high confidence? I'm not a security engineer though, so this is just my personal take on it.

[rossberg]

@jayphelps, actually, a table is writable through the JS API. If a Wasm module shares a table with the outside then anybody with a handle to the table indeed can inject new functions into it -- which is needed for dynamic linking. A module only encapsulates the parts that it doesn't import or export. But all this is well-defined, and it should be comparatively easy to build a formal model of it.

[jayphelps]

@rossberg-chromium absolutely right, I glazed over that. Great great point. 👍

I just meant that wasm itself has no way to modify itself (without you exposing a way through JS FFI), and JS is the weak link in multiple fronts, so if in the future some way is provided to load wasm in isolation without JS + subresource integrity, it seemed like it might maybe satisfy their request.

[jfbastien]

I'll close this issue since I don't think anything is being proposed, it was more of a question?

Feel free to reopen if that's not the case, or keep discussing as well 😄

[gene-eu-zz]

It wasn't a proposal, rather than a question 'is there anybody in wasm world thinking in this direction', answer was elaborate enough (clean loading of wasm files + SRI sounds like a promising model), thank you everyone.