|
|
|
|
|
|
by daniellehmann
1877 days ago
|
|
|
I don't think that's a fair assessment, and it is also not fair to the designers of WebAssembly. They certainly have spent a lot of thoughts on protecting the host (e.g., browser, underlying OS) from _malicious_ WebAssembly code. This is what we call "host security" in the introduction of the paper. 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. 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?