5 ms·
I think the point was that you can’t corrupt the containing process, and wasm separates code from data (Harvard arch?) so you don’t get arbitrary code exec. Of
by olliej 5y ago
I think the point was that you can’t corrupt the containing process, and wasm separates code from data (Harvard arch?) so you don’t get arbitrary code exec. Of course if you process output of the wasm in a trusted environment the compromised wasm could generate something that compromises the host, but the same applies to using separate processes and IPC
- pjmlp 5y agoYou don't need to compromise the host, or trigger RCE, that is the fallacy of WebAssembly security sales pitch. It suffices to find a way to corrupt it's internal state and via this attack vector influence its behaviour. Which yes, boils down to common attacks to separate processes and IPC.
- esprehn 5y agoDo you have a POC of such an attack? If true that would mean web browsers would be vulnerable executing wasm because you can intentionally feed it a program with out of bounds access.
- pjmlp 5y agoCompile heartbleed into WebAssembly. Many that talk about how great the security sandbox is never looked into the security section of the standard. https://webassembly.org/docs/security/ https://webassembly.org/docs/security/ See memory safety and mitigations.
- olliej 5y agoI don't know of anyone who claims that programs in web assembly are safe internally. The security claims are entirely that gaining arbitrary execution inside the wasm sandbox does not give you arbitrary execution in the host. The benefit of a wasm sandbox over a process sandbox is entirely in the overhead reduction - but that does come at the cost of wasm being generally slower than native compilation (oh tradeoffs we will never escape you)
- pjmlp 5y agoPlenty of blog posts that mention how safe it is, because of sandboxing, while disregarding other attack vectors. True, the standard does mention what is and is not safe.
- the_duke 5y agoThis can be mitigated by creating a new WASM instance for every job. Even if there is internal corruption, the most it can affect is the output of the single task, nothing else. That can of course be enough to causes damage, but the attack surface is still much smaller and makes RCE a lot less useful. Especially if capabilities are used to strictly limit the syscall surface for the WASM side (with reference types / interface type resources). WASM isn't a magical security panacea, but it does offer solutions. Of course not using languages that are prone to these attacks in the first place is a better fix.