Hacker News new | ask | show | jobs
by flohofwoe 1803 days ago
According to the article, the C++ code is compiled via Emscripten (presumably to WASM, or maybe to asm.js), so it's running sandboxed either in the WASM or JS runtime. Any potential memory corruption caused by unsafe C++ code is contained within the sandbox (which is the whole point of JS and WASM really).

The security implications are exactly the same as writing the code in any other language (incuding Javascript or Rust). If the sandbox is buggy, then a "safe" language wouldn't help either.
2 comments
detaro 1803 days ago
Just because the attack is contained inside the sandbox doesn't mean it can't do anything, so no, "it's in a sandbox" does not remove all risk automatically.
link
azakai 1803 days ago
You're right that it doesn't remove all risk automatically. You can still corrupt data inside the sandbox.

However, wasm has a very clear sandboxing boundary. The ability of an exploit to escape the sandbox is very small if you are careful there.

IIUC the task here is a user that wants to parse their own files. For that, I think wasm's sandboxing (if used properly) is very useful. Especially since in this case it runs on the web and so we also have the browser's additional isolation (a sandboxed process).

Memory safety is incredibly important, but there isn't a simple answer in the space of tradeoffs, at least not for tasks like this. (For things like running an executable on bare metal that parses arbitrary inputs, obviously things are very different!)

link
pjmlp 1803 days ago
A WASM module basically is like an OS process, from security point of view.

So now think what might happen, when not used properly.

Some form of bounds checking should have been part of the design, like memory tagging.

link
hoytech 1803 days ago
Yes, exactly, otherwise buggy applications wouldn't be a big deal because we could run them on their own dedicated computers.

Section 2.5 of this paper has a good discussion on this: https://cr.yp.to/qmail/qmailsec-20071101.pdf

link
dangerbird2 1803 days ago
In a browser environment, all addressable memory accessible to WASM is more-or-less just a javascript ArrayBuffer object. If you can unintentionally break the browser sandbox with buggy C++ code, someone else has almost certainly already compromised your system with malicious plain ol' javascript.
link