4 ms·

JVM and the CLR are great, but what WASM offers that those do not is sandboxing. Being able to load in external plugins without having to worry about them openi

JVM and the CLR are great, but what WASM offers that those do not is sandboxing. Being able to load in external plugins without having to worry about them opening random files they shouldn't, or starting network connections is some extremely useful functionality. For this case, where the entire application is WASM you could get benefits if you for some reason have a malicious dependency. Instead of it being able to run with full user permissions, it will be limited by the interface offered.

pjmlp 2y ago
Until it becomes a juicy attack vector, worth exploring monetarily like everything else. "Everything Old is New Again: Binary Security of WebAssembly" https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... Just one of the papers slowly coming up on USENIX and other security related conferences. Want a proper sandbox outside the browser? Use OS processes, containers and OS IPC.
- Deukhoofd 2y ago
  To a degree, everything can be exploited, for sure. Memory safety always remains an issue. The sandboxing I was referring to however was the sandboxing from arbitrary syscalls. While some operating systems have functionality to do so (for example OpenBSD's pledge), this is unfortunately still very much a niche feature. Containers solve this problem to a degree, but running GUIs or plugins within them is non-trivial for end users.
- deleted 2y ago
  [deleted]
- actionfromafar 2y ago
  Or use OS processes etc and WASM sandbox.
- vbezhenar 2y ago
  Browser engine is a very juicy attack vector. So it makes sense to use browser engines IMO.
- hackcasual 2y ago
  If you think using containers provides improved security over WASM I don't think you understood the paper. At no point did they demonstrate compromising the host of the WASM program, just corrupting the state of POC's. There are obviously risks associated with that, but nothing that improves by going with isolated/containerized native code. Yes currently lacking ASLR and read-only memory sites increase some risks, but strongly typed function pointers, control flow restricted to function entry points and call stack isolation more than make up for it
  - pjmlp 2y ago
    I think a lot about security, during the last 30 years, and worshiping WASM sales pitch isn't one of them. Also I explicitly mentioned that is the first paper of many others, that are starting to appear on cyber security conferences.
    - hackcasual 2y ago
      It's a 4 year old paper, and the biggest issue it brought up, malleable read-only data, is currently being addressed with the memory control proposal. The fact that a virtual environment can't prevent all types of erroneous program behavior is not particularly noteworthy. The fact of the matter, in particular when comparing WASM against containers, WASM is a generational step forward in terms of permissioning and isolation. For my bonafides, this is me discussing this class of vulnerabilities 8 years ago: https://groups.google.com/g/emscripten-discuss/c/gGjklbJiX1c/m/g7wSxtiLAgAJ https://groups.google.com/g/emscripten-discuss/c/gGjklbJiX1c...
FpUser 2y ago
Personally I've been running native apps on Windows / Linux for ages. No problems so far. I do not see any real value in sandboxing in my environment. What I do see is how crippled sandboxed apps are comparatively to native desktop apps.
- Muromec 2y ago
  >I do not see any real value in sandboxing in my environment I would not like to run stuff with an implicit permission to read my browsing history and all the ssh keys.
shortrounddev2 2y ago
> but what WASM offers that those do not is sandboxing The OS's themselves offer sandboxing, not the app platform. Mac has a locked down permissioning system and Windows has App Containers. Linux has a few sandboxing options available, like flatpak

pjmlp 2y ago

Until it becomes a juicy attack vector, worth exploring monetarily like everything else. "Everything Old is New Again: Binary Security of WebAssembly" https://www.usenix.org/conference/usenixsecurity20/presentation/lehmann https://www.usenix.org/conference/usenixsecurity20/presentat... Just one of the papers slowly coming up on USENIX and other security related conferences. Want a proper sandbox outside the browser? Use OS processes, containers and OS IPC.

Deukhoofd 2y ago
To a degree, everything can be exploited, for sure. Memory safety always remains an issue. The sandboxing I was referring to however was the sandboxing from arbitrary syscalls. While some operating systems have functionality to do so (for example OpenBSD's pledge), this is unfortunately still very much a niche feature. Containers solve this problem to a degree, but running GUIs or plugins within them is non-trivial for end users.
deleted 2y ago
[deleted]
actionfromafar 2y ago
Or use OS processes etc and WASM sandbox.
vbezhenar 2y ago
Browser engine is a very juicy attack vector. So it makes sense to use browser engines IMO.
hackcasual 2y ago
If you think using containers provides improved security over WASM I don't think you understood the paper. At no point did they demonstrate compromising the host of the WASM program, just corrupting the state of POC's. There are obviously risks associated with that, but nothing that improves by going with isolated/containerized native code. Yes currently lacking ASLR and read-only memory sites increase some risks, but strongly typed function pointers, control flow restricted to function entry points and call stack isolation more than make up for it
- pjmlp 2y ago
  I think a lot about security, during the last 30 years, and worshiping WASM sales pitch isn't one of them. Also I explicitly mentioned that is the first paper of many others, that are starting to appear on cyber security conferences.
  - hackcasual 2y ago
    It's a 4 year old paper, and the biggest issue it brought up, malleable read-only data, is currently being addressed with the memory control proposal. The fact that a virtual environment can't prevent all types of erroneous program behavior is not particularly noteworthy. The fact of the matter, in particular when comparing WASM against containers, WASM is a generational step forward in terms of permissioning and isolation. For my bonafides, this is me discussing this class of vulnerabilities 8 years ago: https://groups.google.com/g/emscripten-discuss/c/gGjklbJiX1c/m/g7wSxtiLAgAJ https://groups.google.com/g/emscripten-discuss/c/gGjklbJiX1c...

FpUser 2y ago

Personally I've been running native apps on Windows / Linux for ages. No problems so far. I do not see any real value in sandboxing in my environment. What I do see is how crippled sandboxed apps are comparatively to native desktop apps.

Muromec 2y ago
>I do not see any real value in sandboxing in my environment I would not like to run stuff with an implicit permission to read my browsing history and all the ssh keys.

shortrounddev2 2y ago

> but what WASM offers that those do not is sandboxing The OS's themselves offer sandboxing, not the app platform. Mac has a locked down permissioning system and Windows has App Containers. Linux has a few sandboxing options available, like flatpak