Alternate title: We Learned Nothing About Security From Applets
However, what we look at in the paper is "binary security", i.e., whether _vulnerable_ WebAssembly binaries can be exploited by malicious _inputs_ themselves. Our paper says: Yes, and in some cases those write primitives are more easily obtainable and more powerful than in native programs. (Example: stack-based buffer overflows can overwrite into the heap; string literals are not truly constant, but can be overwritten.)
You say that like the Java Virtual Machine designers didn't do the same thing.
> Modulo implementation bugs (which is orthogonal to the design of the language), WebAssembly applications cannot break out of the sandbox more than arbitrary JavaScript already can.
That has a very familiar sound to it. ;-)
> However, what we look at in the paper is "binary security", i.e., whether _vulnerable_ WebAssembly binaries can be exploited by malicious _inputs_ themselves. Our paper says: Yes, and in some cases those write primitives are more easily obtainable and more powerful than in native programs. (Example: stack-based buffer overflows can overwrite into the heap; string literals are not truly constant, but can be overwritten.)
I think you've highlighted an important subtlety here for sure. Would you say that Java applets were similarly vulnerable?
This paper is only about messing up the WASM heap, which might cause the WASM application to crash, but this doesn't cause damage outside the sandbox.
The design of the Java applet security model did not include being able to escape the sandbox. That was something Microsoft did that deliberately broke the security model. The closest thing Java applets had to "escape the sandbox" was popping up a new window, and even that involved presenting the user with a warning that the window belonged to the applet.