Hacker News Reader

Comment by Deukhoofd | Hacker News Reader

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.

View on HN

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/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.

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.

Or use OS processes etc and WASM sandbox.

Browser engine is a very juicy attack vector. So it makes sense to use browser engines IMO.

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

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.

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...

> 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

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.

>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.

Reply on news.ycombinator.com