i.e. for one, precompiled code is harder to read therefore making it more difficult to meaningfully alter browser code.
How is it more 'sandboxed' than JS, and does this make it less hackable?
"WebAssembly is specified to be run in a safe, sandboxed execution environment." - https://developer.mozilla.org/en-US/docs/WebAssembly/Concepts
Are there properties of the WASM VM memory format that make it more client-side-hack-resistant?
Anything else?
WebAssembly was never designed to be less hackable than JavaScript. WebAssembly modules run within the browser and can be inspected and debugged just like any other JavaScript application. The only additional protection they offer is that of obfuscation. It is a lower level language which makes it harder to decipher the code - although that is not a strong protection!
WebAssembly modules are sandboxed in that one module cannot access the memory, or interact with, another running module. They have their own isolated execution environment. JavaScript is also sandboxed in order to prevent code from one tab or page interacting with another - and more importantly preventing it from accessing the underlying host OS!
Webassembly uses linear memory, which is a contiguous block of memory, that is typical used to create a heap. It can be exported to the host environment, which means that the hosting JavaScript code can directly read and write to it as a byte array.
In summary, WebAssembly is not less hackable and has a different sandbox. If these are the trains you’re looking at this technology, perhaps it’s time for a rethink?
On the web, WebAssembly runs in the same sandbox as JavaScript, so WebAssembly cannot affect its host machine in any way that could not also be done with pure JavaScript. But WebAssembly goes further and does make it safer to run untrusted code because of how its imports work.
When a WebAssembly module is instantiated, it is supplied with a set of imported functions. These imports are the only host functions that the module has access to, and they cannot be changed once the module has been instantiated. Without imports, a WebAssembly module can only express pure computation and can only affect the state of its own memory. That means that if you don't supply any imports that can make network requests, you can be certain that the WebAssembly module cannot make network requests. Contrast this to JavaScript, where figuring out whether a program uses a particular API is undecidable in general.
That does not mean that the code in the WebAssembly module cannot have bugs or security vulnerabilities. For example, buffer overrun attacks on buggy C programs are still possible when those C programs are compiled to WebAssembly, but the difference is that the worst they can do is determined by the imports, which are easy to inspect. So if you import eval into your buggy C WebAssembly module you might have serious problems, but if you only import console.log, the worst an attacker could do is spam your console.
I don't view WebAssembly being low level as relevant to security. WebAssembly modules are no harder to read than minimized or obfuscated JavaScript, and the difference all but disappears when you consider asm.js-style JavaScript. Certainly it is harder to read a WebAssembly module than a pretty-printed JavaScript program, but that doesn't really get you anywhere in terms of security.
