Heap memory corruption in GitHub's Markdown table parsing extension • Hacker News Board

Re: Heap memory corruption in GitHub's Markdown table parsing extension

#41

Post by the_duke » Sat, Mar 05, 2022, 10:38 AM UTC

pjmlp wrote: post #28

olliej wrote: post #26

Earlier quoted context omitted.

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

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.

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.

Re: Heap memory corruption in GitHub's Markdown table parsing extension

#42

Post by camgunz » Sat, Mar 05, 2022, 2:52 PM UTC

the_duke wrote: post #41

pjmlp wrote: post #28

Earlier quoted context omitted.

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.

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 / i…

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?

Re: Heap memory corruption in GitHub's Markdown table parsing extension

#43

Post by pjmlp » Sat, Mar 05, 2022, 4:36 PM UTC

camgunz wrote: post #42

the_duke wrote: post #41

Earlier quoted context omitted.

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 / i…

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.

Re: Heap memory corruption in GitHub's Markdown table parsing extension

#44

Post by staticassertion » Sat, Mar 05, 2022, 11:00 PM UTC

the_duke wrote: post #40

staticassertion wrote: post #15

Earlier quoted context omitted.

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…

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.

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.