Explain security

[jfbastien]

WebAssembly's security model aims at protecting users from buggy or malicious .wasm files. This doesn't help developers write secure application! Our design should make that distinction clear, explain how WebAssembly implements that security, and what tools WebAssembly expect to be available to help developers create secure applications (this relies on offering the right primitives in WebAssembly).

This is mostly an issue for myself to add this in the design.

[MattPD]

Hi!

I have a question: Would it make sense to elaborate on the following in this context:

"Other than that, programs which invoke undefined behavior at the source language level may be compiled into WebAssembly programs which do anything else, including corrupting the contents of the application heap, calling APIs with arbitrary parameters, hanging, trapping, or consuming arbitrary amounts of resources (within the limits)."
https://github.com/WebAssembly/design/blob/master/CAndC++.md#undefined-and-implementation-defined-behavior

What I'm thinking of is providing context / references which may be (perhaps) of use for the web developers coming from non-native backgrounds -- by providing examples and further discussion.

For instance, CERT's MSC14-C. Do not introduce unnecessary platform dependencies lists four different kinds of Nonportable Behavior (Unspecified Behavior, Undefined Behavior, Locale-specific Behavior, Implementation-defined Behavior) with examples. MSC15-CPP. Do not depend on undefined behavior links to vulnerability C compilers may silently discard some wraparound checks, which may be particularly noteworthy in this context (Robert Seacord discusses this in more detail in "Silent Elimination of Bounds Checks").

More in-depth treatments:

• What Every C Programmer Should Know About Undefined Behavior #1/3
• What Every C Programmer Should Know About Undefined Behavior #2/3
• What Every C Programmer Should Know About Undefined Behavior #3/3
• A Guide to Undefined Behavior in C and C++, Part 1
• A Guide to Undefined Behavior in C and C++, Part 2
• A Guide to Undefined Behavior in C and C++, Part 3

Other potentially relevant advice:

• INT02-CPP. Understand integer conversion rules
• INT08-CPP. Verify that all integer values are in range
• INT10-CPP. Do not assume a positive remainder when using the % operator
• INT18-C. Evaluate integer expressions in a larger size before comparing or assigning to that size
• INT32-C. Ensure that operations on signed integers do not result in overflow

[jonathanKingston]

Would having a unique CSP header for controlling wasm files help? I feel like site owners might want to prevent subresources from loading wasm.

[lukewagner]

That's an interesting question. Definitely we should allow sites to disallow dynamic loading and evaluation of WebAssembly in the same cases they disallow eval and Function (this would just fall out of ES6 module integration and CSP checks on the Loader path). Past that, though, since WebAssembly will be capability-equivalent to JS, I wouldn't think distinguishing the two would be necessary.

[jfbastien]

It's worth pointing at #53 for a discussion of some of the security concerns with dynamic linking.

[jonathanKingston]

@jfbastien yup CORS and SRI should be a available to developers where possible.

@lukewagner I guess it depends on the low level access to resource that wasm will enable. As you say out of the box it is just JS. However it seems the overarching goal of wasm is the closest thing to the machines metal possible; a CSP directive to globally control would be a nice to have.
Over time a more granular approach to the other features would be better too.

The other immediate possibilities are utilising the permissions API for other low level access.

[lukewagner]

Well, close to the metal in a performance sense. From a security, permissions and sandboxing perspective, there is no discussion of having WebAssembly diverging from JS.

[jonathanKingston]

That wasn't the feeling I got from both the post-MVP and Brendan Eichs announcements but ok 👍

[lukewagner]

I think what you're referring to is that we've agreed that, post-MVP, WebAssembly semantics would be allowed to diverge from what could be efficiently polyfilled in JS. This divergence would be around computational features, not anything to do with security/permissions. That means that, while they couldn't be polyfilled efficiently, new features could be simulated by a WebAssembly interpreter written in JS (Emterpreter-style). It'd probably be good to add a note to this effect to bound what we mean by "diverge from JS".

[jonathanKingston]

Yup that would be a good enhancement to the document certainly, I might have read the document too fast but it didn't seem to make that clear.

I think it was one of Eichs talks about adding more threading and memory features that made me think wasm would get new features. I suspect these are likely to be added to JavaScript too and be subject to the usual scrutiny of new features.

[lukewagner]

"No different from security POV than JS" is now in Web.md.