[daniellehmann]

Daniel here, one of the authors.

You are right, some of the issues highlighted in the paper could be solved by compilers targeting WebAssembly. One such mitigation that is (currently) missing are stack canaries. In contrast, stack canaries are typically employed by compilers when targeting native architectures. They also cost performance there (typically single digit percentages), but evidently compiler authors have decided that this cost is worth the added security benefit, since fixing "old C issues" in all legacy code in existence is not realistic.

Note however, that other security issues highlighted in the paper _are_ characteristics of the language, notably linear memory without page protection flags. One consequence of this design is that there is no way of having "truly constant" memory -- everything is always writable. I do think that this is surprising and certainly weaker than virtual memory in native programs, where you _cannot_ overwrite the value of string literals at runtime.

[titzer]

The decision to not (yet) have finer-grained protection for WebAssembly memory pages was in part motivated by the JS API surface in the web embedding. WebAssembly memories are exposed to JS as ArrayBuffers, and optimizing JITs can and do optimize ArrayBuffer access down to naked stores and loads. In addition to the optimized JIT code, ArrayBuffers are used throughout the webstack for moving data into and out of programs (read: Chrome's 6 million lines of code). The entire webstack is not really prepared for read-only ArrayBuffers causing signals underneath.

That said, we always knew a day would come where WebAssembly would get the ability to set more page protections. For non-web embeddings, this is easier, but as of yet, none of the engines I know of have either an API or are really prepared for the implications of this. I am still bullish on eventually getting that capability, though.

Thanks for your paper.

[daniellehmann]

Thanks a lot for the additional background, and also for all the work on WebAssembly. It is a very cool language and having it available with linear memory now is much better than if it were still in the works due to figuring out page protections.

As you said, I just hope page protections can still be added later (somebody needs to specify it, embedders need to be able to implement them, toolchains need to pick it up, etc.).

Maybe memory vulnerabilities inside WebAssembly programs can also be mitigated in other ways that do not require such pervasive changes, e.g., by keeping modules small and compiling each "protection domain" (e.g., library) into its own module, or to have a separate memory. I am not sure about the performance cost of such an approach, though.

[miohtama]

Thank you for the clarification!