| > This doesn't really seem to offer anything useful, or even contain new information. You are right in that we do not try to attack a concrete host implementation or aim to break out of the sandbox. I disagree, however, that security inside a WebAssembly binary is irrelevant. If an attacker can arbitrarily read/write in linear memory, it depends on the imported host functions what can be done. The larger WebAssembly applications are (and we believe they will become larger in the future, and incorporate DOM functions, as in our PoC application), the higher the risk that host APIs can be abused. This is troubling especially where there is no sandbox (on some standalone VMs), but even in browsers (where it opens the door for a new type of cross-site scripting). For example, even if you only call JS eval() with a constant string in your C code, because WebAssembly has no truly constant memory, this can give XSS to an attacker with a memory write primitive inside linear memory. > The html page there seems to be missing the "main.js" to see what's happening. :( Oops, good point. They are now pushed, sorry about that. > main.js, which looks (without checking) like it came from Emscripten That's correct, you can also check the build script: https://github.com/sola-st/wasm-binary-security/blob/master/... |
On one hand, the problem doesn't seem to be any different than happens with standard JS. The exploit was possible only because the wasm (literally) did no input validation. And "validate all input" is the first thing web programmers learn. (or very close to first ;>)
On the other hand, it is a vector. And we've seen plenty of cases where vectors are chained together in novel ways to enable unexpected attacks. So there's that. ;)
> Oops, good point. They are now pushed, sorry about that.
No worries, thanks for getting that done. :)