4 ms·

Security Chasms of WASM [pdf]

78 points by rfinney 8y ago

pitaj 8y ago
As far as I can tell, these exploits have very little to do with WASM, and more to do with exploits around the toolchains and code running on it.
- Justin_Engler 8y ago
  If you're looking for bugs in WASM implementations, take a look at https://www.blackhat.com/us-18/briefings/schedule/#the-problems-and-promise-of-webassembly-11219 https://www.blackhat.com/us-18/briefings/schedule/#the-probl... (https://news.ycombinator.com/item?id=17782552 https://news.ycombinator.com/item?id=17782552 previously posted a week ago) Our paper/talk was more about the security implications of using WASM in your stack.
  - AboutTheWhisles 8y ago
    Are you talking about bugs or are you talking about inherent security vulnerabilities in the design?
    - Justin_Engler 8y ago
      Less "inherent vulnerabilities" than "If you're using a memory unsafe language (like C), the protections WASM gives you aren't enough to mitigate every possible vuln you might have had in your C code" The WASM platform does provide some really cool protections, but it's not a silver bullet, you still need to fix your C code.
      - monocasa 8y ago
        > The WASM platform does provide some really cool protections, but it's not a silver bullet, you still need to fix your C code. I mean, the way you're phrasing it, that's true of every system. IIRC seL4 had a couple bugs where the code _and_ the formal model both got it wrong in the same way, and it therefore passed the proof. The guarantees that wasm attempts to provide are that it's ok for me as a user to run random code in a wasm sandbox, rather than that code is inherently better at it's internal security by being in a sandbox. ie. wasm doesn't attempt to make the developer's job any easier, other than making it more likely that users will be willing to run their code. Like, I don't think my c code is any safer when I run it on a system with a hypervisor.
        posterboy 8y ago
        > IIRC seL4 had a couple bugs where the code _and_ the formal model both got it wrong in the same way, and it therefore passed the proof. I haven't heard this one yet. How did they find it, then?
kablaa 8y ago
Hey! I helped write this paper. Let me know if you have questions about it.
AndrewGaspar 8y ago
This paper is important. It doesn't point out anything that you shouldn't already know if you're an experienced systems programmer, but may be a good reminder that WebAssembly's sandbox isn't the last word on security. You still need to be on alert for things that can trigger XSS, which can be easier when you have a memory unsafe language like C or C++ in your stack. There's a good point in there about how node.js is exposed to all these vulnerabilities too.
snaky 8y ago
Who had abbreviated WebAssembly as WASM? I know I know nobody use Watcom assembler (wasm) now, but still.

78 points by rfinney 8y ago

As far as I can tell, these exploits have very little to do with WASM, and more to do with exploits around the toolchains and code running on it.

Justin_Engler 8y ago
If you're looking for bugs in WASM implementations, take a look at https://www.blackhat.com/us-18/briefings/schedule/#the-problems-and-promise-of-webassembly-11219 https://www.blackhat.com/us-18/briefings/schedule/#the-probl... (https://news.ycombinator.com/item?id=17782552 https://news.ycombinator.com/item?id=17782552 previously posted a week ago) Our paper/talk was more about the security implications of using WASM in your stack.
- AboutTheWhisles 8y ago
  Are you talking about bugs or are you talking about inherent security vulnerabilities in the design?
  - Justin_Engler 8y ago
    Less "inherent vulnerabilities" than "If you're using a memory unsafe language (like C), the protections WASM gives you aren't enough to mitigate every possible vuln you might have had in your C code" The WASM platform does provide some really cool protections, but it's not a silver bullet, you still need to fix your C code.
    - monocasa 8y ago
      > The WASM platform does provide some really cool protections, but it's not a silver bullet, you still need to fix your C code. I mean, the way you're phrasing it, that's true of every system. IIRC seL4 had a couple bugs where the code _and_ the formal model both got it wrong in the same way, and it therefore passed the proof. The guarantees that wasm attempts to provide are that it's ok for me as a user to run random code in a wasm sandbox, rather than that code is inherently better at it's internal security by being in a sandbox. ie. wasm doesn't attempt to make the developer's job any easier, other than making it more likely that users will be willing to run their code. Like, I don't think my c code is any safer when I run it on a system with a hypervisor.
      - posterboy 8y ago
        > IIRC seL4 had a couple bugs where the code _and_ the formal model both got it wrong in the same way, and it therefore passed the proof. I haven't heard this one yet. How did they find it, then?

kablaa 8y ago

Hey! I helped write this paper. Let me know if you have questions about it.

AndrewGaspar 8y ago

This paper is important. It doesn't point out anything that you shouldn't already know if you're an experienced systems programmer, but may be a good reminder that WebAssembly's sandbox isn't the last word on security. You still need to be on alert for things that can trigger XSS, which can be easier when you have a memory unsafe language like C or C++ in your stack. There's a good point in there about how node.js is exposed to all these vulnerabilities too.

snaky 8y ago

Who had abbreviated WebAssembly as WASM? I know I know nobody use Watcom assembler (wasm) now, but still.