Hacker News Reader

Comment by angrygoat | Hacker News Reader

WASM and the surrounding Javascript model offer a lot of opportunities to minimise the damage if something gets exploited.

Say you are running OCR via some C library you have compiled to WASM: wrap that functionality up with an interface, compile that to WASM, and only pass it the image data you're happy for it to see. If someone exploits that binary with a malicious image, there's nothing inside the container except the code and the image itself, so hopefully the damage is contained.

If folks start compiling large amounts of their functionality into one single chunk of WASM, which has a complex interface with the DOM/JS, then I can see how these exploits could become an issue.

View on HN

> some C library you have compiled to WASM: wrap that functionality up with an interface, compile that to WASM, and only pass it the image data you're happy for it to see

That is good advice. Separately compiling C code into individual modules with small interfaces and as little host imports as possible does make exploitation harder. This is also one of the propositions we make in the mitigations section of the paper.

> If folks start compiling large amounts of their functionality into one single chunk of WASM

However, I also believe that is what will happen soon. Many people are eager to use WebAssembly for more parts of the front-end (and also because they want to develop in Go, Rust, etc., see the increasing number of DOM-libraries for WebAssembly). With more code being linked into a single WebAssembly module, it becomes more important to look into security inside a single WebAssembly module.

Even then. If the input images are from untrusted source, you need to scrupulously treat the OCR output as untrusted too, and that it is actually OCRing and not mining crypto (say, using image library exploit + OCR math library functions), etc. etc.

True, but there's not much point mining for crypto if the WASM module's gateway to the DOM/JS/... doesn't let you export the result.

> If folks start compiling large amounts of their functionality into one single chunk of WASM

WebAssembly multi memory proposal and nanoprocesses (one of WASI initiative) should solve all this problems as well

But for now dynamic linking of two wasm modules is not even possible

That OCR library can then vouch that a security QR code has more permissions that it was actually supposed to provide, and then isAdmin() returns true...

> If folks start compiling large amounts of their functionality into one single chunk of WASM, which has a complex interface with the DOM/JS, then I can see how these exploits could become an issue.

But unless you can break the sandbox isolation the worse you can get is what you get today with JsFuck, just faster.

Reply on news.ycombinator.com