> 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/...

Hmmm, I'm kind of in two minds about this.

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. :)

The exploit is against a vulnerable library (the actual input file is here: https://github.com/sola-st/wasm-binary-security/blob/master/...)

If you have a wasm application with vulnerabilities (e.g. in the libraries) there are no mitigations that native binaries provide, so simple buffer overflows give you RCEs again. It's still within the sandbox, but the threat is as severe as running eval on user supplied inputs as there might be useful stuff in that sandbox.

Isn't it (exactly?) the same as finding a vulnerable JS library, and providing bad input to that?

That aside, if the C-to-wasm compiler were to add some of the safeguards mentioned it does sound like it'd go some way towards lessening the potential impact.

Yes, if there was a library that eval'd unsanitised input the damage potential is the same.

The practical difference is that it's a lot harder to assure code written in unsafe languages is free of defects like this since they manifest as benign operations (every write to a buffer is a potential vector) rather than obviously dangerous operations. Concretely, you could grep for eval and convince yourself that each use is OK (assuming it's rare - it ought to be) but you couldn't do that for common language constructs that could be exploitable like writes to arrays/pointers.