4 ms·
Programs running natively on a computer have some security measures in place that wasm binaries lack, while wasm has other security measures in place that nativ
by est31 5y ago
Programs running natively on a computer have some security measures in place that wasm binaries lack, while wasm has other security measures in place that native programs lack. Quoting the "Everything Old is New Again: Binary Security of WebAssembly" paper:
> Comparing the exploitability of WebAssembly binaries with native binaries, e.g., on x86, shows that WebAssembly re-enables several formerly defeated attacks because it lacks modern mitigations. One example are stack-based buffer overflows, which are effective again because WebAssembly binaries do not deploy stack canaries. Moreover, we find attacks not possible in this form in native binaries, such as overwriting string literals in supposedly constant memory.
https://news.ycombinator.com/item?id=24216764 https://news.ycombinator.com/item?id=24216764
https://www.unibw.de/patch/papers/usenixsecurity20-wasm.pdf https://www.unibw.de/patch/papers/usenixsecurity20-wasm.pdf
- IshKebab 5y agoYes but the impact of a wasm buffer overflow is completely different to a C buffer overflow. A C buffer overflow can (sometimes) let you execute arbitrary code. A wasm one will just result in data corruption. That data corruption may be exploitable (e.g. if it lets you overwrite a password) but those kinds of attacks are much much rarer than the kind that wasm prevents.
- pjmlp 5y agoBeing rarer doesn't make them nonexistent, as the WebAssembly advocacy tends to be around most places.
- IshKebab 5y agoThis blog post explicitly calls out that out: > 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. I don't think I've ever heard any WebAssembly advocates saying that it magically solves all security issues.