[daniellehmann]

Hi everyone, Daniel here (one of the authors, I am the PhD student in the video). Great to see the paper submitted and discussed :-)

Sorry for being a bit late to the discussion, I will try to answer the questions in detail that were asked below.

I want to clarify one misunderstanding that seems to come up several times, namely the distinction between "host security" and "security of the WebAssembly program itself". WebAssembly does have measures and a good design for host security. E.g., in the browser, WebAssembly programs are run in a sandbox (just as JavaScript is), and writes inside WebAssembly's linear memory should never affect values outside of linear memory (e.g., VMs insert bounds checks when reading/writing from/to WebAssembly pointers). Those techniques protect against malicious WebAssembly binaries, which is of course important in the Web.

Here, we look at a different side of WebAssembly's security story: What if the WebAssembly binary is vulnerable and gets fed malicious input? In this attacker model, we can at most do what the host environment allows us to do. But especially for large WebAssembly programs with lots of imports, or WebAssembly binaries for standalone VMs (outside of the browser, without a tried-and-tested sandbox), this can still be a lot of attacker capability! And when we look into the protections inside WebAssembly's linear memory (not between linear memory and host memory), we find that there are very little. All linear memory is always writable, no stack canaries, no guard pages, no ASLR, no safe unlinking in smaller allocators etc. This is worrying as more code gets linked together into a single WebAssembly binary.

If you have any further questions, I am more than happy to answer, here and also via email. Thanks again for the interest!

[afiori]

To my understanding one of the design constraints behind webassembly semantics where given by wanting to keep implementation burden low for browsers.

In particular my understanding is that most of MVP WebAssembly almost a subset of asm.js in term of expressivity.

Do some of the safety measures you consider translate well in this model?

[daniellehmann]

> Do some of the safety measures you consider translate well in this model?

Yes, I think several mitigations could be deployed without requiring a change to the language, only by changing compilers and runtime libraries:

* Stack canaries on the unmanaged stack: For storing the reference canary value, you need some "safe" location that cannot be overwritten by regular memory writes. I believe in x86, thread local storage (TLS) / the fs segment register is used. In WebAssembly, one could use a non-mutable global scalar variable, which could only be overwritten by a matching global.set instruction (which cannot be inserted by an attacker). Then, before returning from a function (or really at any point you want to check the integrity of linear memory), you could compare the canary value against this global, as you would in native architectures.

* Allocator hardening, e.g., safe unlinking doesn't require any language support, the allocator just needs to do it (and live with the slightly increased code size cost).

Other mitigations would require language extensions. E.g., for finer grained control-flow integrity (taking source types into account, not just WebAssembly primitive types), one would require multiple table (part of the reference types proposal). Then, only functions with compatible types should be stored in the same indirect call table.

ASLR, unmapped pages, and constants in linear memory are harder, I believe. For ASLR, WebAssembly's 32-bit pointers will most likely provide too little entropy. Unmapped pages and "true constants" would require some host API to make portions of the memory non-writable/readable, but I don't know of any proposal to do so.

> wanting to keep implementation burden low for browsers

> WebAssembly almost a subset of asm.js

Yes, that is also my understanding as to why we are at the current situation. (But I did not take part in WebAssembly's design, so I cannot claim any authority.)