5 ms·

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 sa

• pjmlp 5y ago
  WASM doesn't protect against heap corruption, because bounds checking doesn't apply inside a linear memory segment.
  • 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 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.
      • esprehn 5y ago
        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 5y ago
          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/ https://webassembly.org/docs/security/ See memory safety and mitigations.
      • olliej 5y ago
        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 5y ago
          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 5y ago
        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 5y ago
          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 5y ago
            Nope, just how it gets sold.
• staticassertion 5y ago
  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.
  • nwmcsween 5y ago
    Welcome to 1996 with ucspi
    • pjmlp 5y ago
      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.
  • the_duke 5y ago
    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 5y ago
      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.