3 ms·

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 l

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.

rini17 6y ago
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.
- angrygoat 6y ago
  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.
maxgraey 6y ago
> 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
- maxgraey 6y ago
  But for now dynamic linking of two wasm modules is not even possible
daniellehmann 6y ago
> 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.
afiori 6y ago
> 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.
pjmlp 6y ago
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...

rini17 6y ago

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.

angrygoat 6y ago
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.

maxgraey 6y ago

> 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

maxgraey 6y ago
But for now dynamic linking of two wasm modules is not even possible

daniellehmann 6y ago

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

afiori 6y ago

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

pjmlp 6y ago

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