3 ms·

Are you perhaps thinking of "Everything Old is New Again: Binary Security of WebAssembly"? ( https://www.usenix.org/system/files/sec20-lehmann.pdf https://www.u

Are you perhaps thinking of "Everything Old is New Again: Binary Security of WebAssembly"? ( https://www.usenix.org/system/files/sec20-lehmann.pdf https://www.usenix.org/system/files/sec20-lehmann.pdf ) In any case, I think you've misunderstood the security properties. WASM can have weaker security within the sandbox because it doesn't have access to some of the more sophisticated mitigation measures that native code does, but the security of the sandbox boundary itself is very solid. The part of the article that you quote is accurate in the sense that I believe it was meant - the code cannot jump to unexpected parts of the rest of the program (outside the sandbox) and cannot access memory outside of a specified region (the sandboxed memory). A vulnerability might allow the target code to jump to somewhat unexpected parts inside the sandbox, or buffer overflows inside the sandbox, but not outside. As such, it's actually a really effective application of a WASM sandbox!

titzer 5y ago
> WASM can have weaker security within the sandbox because it doesn't have access to some of the more sophisticated mitigation measures that native code does, And that's mostly read-only data pages. The primary blocker there is how to integrate that capability with ArrayBuffer in the web platform, since Wasm memories can be exposed (or aliased) as ArrayBuffer objects, and most engines aren't prepared to encourage non-writable holes in ArrayBuffers.
pjmlp 5y ago
Triggering a fire inside the castle might be enough to change the output of calls being done into the sandbox, it doesn't need to escape it to be exploitable.
- miloignis 5y ago
  They're addressing this as well - from the article: > This, in turn, makes it easy to apply without major refactoring: the programmer only needs to sanitize any values that come from the sandbox (since they could be maliciously-crafted), a task which RLBox makes easy with a tainting layer.
  - pjmlp 5y ago
    Programmer only needs to sanitize.... You mean like all those great programmers that keep introducing bugs like the one recently found out by Project Zero?
vlovich123 5y ago
Yes! Thanks so much for finding it, that's exactly the paper. > A vulnerability might allow the target code to jump to somewhat unexpected parts inside the sandbox, or buffer overflows inside the sandbox, but not outside. As such, it's actually a really effective application of a WASM sandbox! Again, don't get me wrong. This is a very interesting idea to explore. The paper does point out ways that the host JS environment (which in this case can be considered the FF native process) can be exploited. Not as easily as a heap overflow, but not necessarily trivially either. I think both that paper & this post lay out an interesting idea on how to better lock down native extensions.

titzer 5y ago

> WASM can have weaker security within the sandbox because it doesn't have access to some of the more sophisticated mitigation measures that native code does, And that's mostly read-only data pages. The primary blocker there is how to integrate that capability with ArrayBuffer in the web platform, since Wasm memories can be exposed (or aliased) as ArrayBuffer objects, and most engines aren't prepared to encourage non-writable holes in ArrayBuffers.

pjmlp 5y ago

Triggering a fire inside the castle might be enough to change the output of calls being done into the sandbox, it doesn't need to escape it to be exploitable.

miloignis 5y ago
They're addressing this as well - from the article: > This, in turn, makes it easy to apply without major refactoring: the programmer only needs to sanitize any values that come from the sandbox (since they could be maliciously-crafted), a task which RLBox makes easy with a tainting layer.
- pjmlp 5y ago
  Programmer only needs to sanitize.... You mean like all those great programmers that keep introducing bugs like the one recently found out by Project Zero?

vlovich123 5y ago

Yes! Thanks so much for finding it, that's exactly the paper. > A vulnerability might allow the target code to jump to somewhat unexpected parts inside the sandbox, or buffer overflows inside the sandbox, but not outside. As such, it's actually a really effective application of a WASM sandbox! Again, don't get me wrong. This is a very interesting idea to explore. The paper does point out ways that the host JS environment (which in this case can be considered the FF native process) can be exploited. Not as easily as a heap overflow, but not necessarily trivially either. I think both that paper & this post lay out an interesting idea on how to better lock down native extensions.