[esprehn]

This seems like a good opportunity to use wasm on the server to sandbox the processing of user provided content. Of course they could also try rewriting in a safer language, but given that this already exists and handles all their content, wasm might be a simple defense in depth protection.

[staticassertion]

What Dropbox did for this sort of thing is ideal. You spawn a child process that has two file handles piped to/from the parent - stdin, stdout.

That child process does the scary stuff - parsing. Parsing requires zero system calls. Reading to/from the parent requires only read and write, but not open, so they can only read and write to those file descriptors.

And exit.

That's it. Seccomp v1 is trivial to apply, gives 4 system calls, and makes the process virtually useless to an attacker. If you want to get fancy and allow for multithreading you can use seccomp v2 and create your threadpool before you drop privs, and probably add futex and memmap.

You pay a latency cost but the security win is huge.

[the_duke]

That's a lot of complicated, non-portable steps, with many subtle semantics that can easily be implemented incorrectly.

Running the code in a Wasm sandbox sounds a whole lot easier and less error prone. You do have to trust the Wasm engine, but nothing else. And you don't need in-depth knowledge of OS security mechanisms.

[staticassertion]

No one cares about portability on the backend. This is a service - github dictates where it runs. I don't see this as being any more complex or involving any more "subtle semantics" than bringing an entire VM and new compiler target along.

Nothing I mentioned requires knowledge of OS security mechanisms beyond what I've described in my short comment.

[nwmcsween]

Welcome to 1996 with ucspi

[pjmlp]

One thing that I have come to accept is that if one cares about security, the only path is multiple processes, shared library plugins and background threads are a window waiting to be broken.

[pjmlp]

WASM doesn't protect against heap corruption, because bounds checking doesn't apply inside a linear memory segment.

[olliej]

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]

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.

[olliej]

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)

[pjmlp]

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.

[the_duke]

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.

[camgunz]

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?

[pjmlp]

Nope, just how it gets sold.

[esprehn]

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.

[pjmlp]

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.