3 ms·

> If you can stomach the perf tradeoffs, compiling to WASM is much easier than this This WASM? https://www.theregister.com/2021/11/04/webassembly_stack_canarie

by noja 5y ago

> If you can stomach the perf tradeoffs, compiling to WASM is much easier than this This WASM? https://www.theregister.com/2021/11/04/webassembly_stack_canaries/ https://www.theregister.com/2021/11/04/webassembly_stack_can...

feanaro 5y ago
Those are not sandbox escapes, those are missing intra-program defences which make it easier for a e.g. buffer overflow to be used for program manipulation. That still doesn't allow you to escape the sandbox in itself.
- pjmlp 5y ago
  Not being able to escape the sandbox is meaningless if data corruption makes an exploit possible.
  - feanaro 5y ago
    How is it meaningless? Your program's integrity is compromised, but the host is not. That's a meaningful difference.
    - pjmlp 5y ago
      Not when an exploit is made possible thanks to integrity being compromised. The castle walls stand, yet everything burns thanks being able to turn a candle into the table.
- aseipp 5y ago
  They don't let you perform sandbox escapes but that doesn't necessarily matter if all of the important data is inside the sandbox, and it has enough capabilities to meaningfully exfiltrate. seccomp has this problem in spades; most apps that "use seccomp" make practically every syscall under the sun available to make the policy apply cleanly. This is just an example not to be taken as totally illustrative. But very few people design their programs around seccomp or another sandbox mechanism, I find. This doesn't apply obviously to cases where you design around having a sandbox, and at that point, I think the differences between something like WASM and SAPI or whatever are a lot murkier and more technical. One thing about WASM that I feel is worth mentioning, which isn't technical so much as social, is that there's a lot of appeal/interest around simply "lift-and-shift" existing native code onto webassembly runtimes. That's good because that existing code is useful, but those apps aren't often designed with such sandbox architectures in mind. They often are designed (or at least consider) having binary-level mitigations applied, though. So I think this natural overlap in the set of use cases people have is what might give people pause. This is similar to the seccomp problem; retrofitting is a very big appeal even though it has some conceptual issues. This isn't some kind of indictment but if you're going to do an honest evaluation of these approaches I feel this background is worth keeping in mind. I think if you designed an app with a sandbox architecture by default the best sandbox is the one you trust, WASM vs whatever be damned.

by noja 5y ago

feanaro 5y ago

Those are not sandbox escapes, those are missing intra-program defences which make it easier for a e.g. buffer overflow to be used for program manipulation. That still doesn't allow you to escape the sandbox in itself.

pjmlp 5y ago
Not being able to escape the sandbox is meaningless if data corruption makes an exploit possible.
- feanaro 5y ago
  How is it meaningless? Your program's integrity is compromised, but the host is not. That's a meaningful difference.
  - pjmlp 5y ago
    Not when an exploit is made possible thanks to integrity being compromised. The castle walls stand, yet everything burns thanks being able to turn a candle into the table.
aseipp 5y ago
They don't let you perform sandbox escapes but that doesn't necessarily matter if all of the important data is inside the sandbox, and it has enough capabilities to meaningfully exfiltrate. seccomp has this problem in spades; most apps that "use seccomp" make practically every syscall under the sun available to make the policy apply cleanly. This is just an example not to be taken as totally illustrative. But very few people design their programs around seccomp or another sandbox mechanism, I find. This doesn't apply obviously to cases where you design around having a sandbox, and at that point, I think the differences between something like WASM and SAPI or whatever are a lot murkier and more technical. One thing about WASM that I feel is worth mentioning, which isn't technical so much as social, is that there's a lot of appeal/interest around simply "lift-and-shift" existing native code onto webassembly runtimes. That's good because that existing code is useful, but those apps aren't often designed with such sandbox architectures in mind. They often are designed (or at least consider) having binary-level mitigations applied, though. So I think this natural overlap in the set of use cases people have is what might give people pause. This is similar to the seccomp problem; retrofitting is a very big appeal even though it has some conceptual issues. This isn't some kind of indictment but if you're going to do an honest evaluation of these approaches I feel this background is worth keeping in mind. I think if you designed an app with a sandbox architecture by default the best sandbox is the one you trust, WASM vs whatever be damned.