Hacker News new | ask | show | jobs
by pjmlp 1563 days ago
You 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.

3 comments

I 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)

Plenty 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.

This 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.

I'm naive when it comes to WASM, but the first thing I thought is "that sounds conceptually the same as spawning a child process." Are there significant differences?
Nope, just how it gets sold.
Do 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.
Compile 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/

See memory safety and mitigations.