Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

WASM is more secure than a hypervisor, since it prevents code injection.


It is trivial to modify function pointers, implemented as indirect calls and "read-only" data in wasm.


Yes, WASM in combination with an unsafe language is less secure than memory safe languages, but more secure than a hypervisor. You can also use WASM with a memory safe language.


WASM is less secure than a regular process boundary, and far less secure than a hypervisor. I'm not sure where you're getting this from? Things like spectre mitigations in CPUs are not doing anything for the likes of WASM, after all, they only target process & ring boundaries. It's why you have to enable COOP and COEP to use thread with WASM - because the security for WASM's threads comes from the CPU enforcing process boundaries, not from WASM's sandbox.


If we are concerned with leakage of user data available in your own web program, then unsafe WASM code is more secure than unsafe code in a hypervisor because it prevents RCE, which results in full control of the hypervisor environment, which also enables transient attacks against the host environment, if there are vulnerabilities in your hypervisor (previously hypervisors had to be patched for Spectre). If we are talking about host platform protection against arbitrary malicious code, information leakage from neighboring processes/tabs, WASM is no different from a process boundary, at least in chrome, because that's how it's implemented. It's an implementation detail independent of WASM. Could as well be implemented with hardware virtualization, but it would make interfacing with browser APIs more expensive, probably to the point of impracticality.


Are you trying to say that code compiled with CFI is less vulnerable than code that wasn't? In which case sure, but that's entirely orthogonal to WASM. Code inside WASM isn't otherwise inherently protected. Code reuse attacks via indirect calls are still possible, as are of course side channel attacks and data leaks.

And since WASM uses linear memory and lacks things like ASLR, the code in the sandbox cannot achieve the same level of protection it could if it was in a hypervisor.


No need for RCE when data corruption suffices to change code paths.


It doesn't matter if it's rust or not. You can still modify read only data and still redirect indirect calls. You can still modify the stack and the heap. Rust changes nothing.

Also, not sure where the comparison to a hypervisor is coming into play. As @kllrnohj mentioned hypervisors are relying on actual hardware.


I'm not a rust expert, but I thought rust without unsafes should prevent such things at the compile time. C# and Java will be compiled into WASM differently, I believe no less securely than JVM or .NET. Having information leaks is still better than arbitrary code execution.


No safe language in the world prevents anything if the attacker can change the binary contents, it is no longer the code produced by the compiler.

That is why we have signed binary execution to start with, WASM doesn't support any of this.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: