logoalt Hacker News

cogman10yesterday at 7:32 PM1 replyview on HN

It is much smaller.

WASM today has no access to anything that isn't given to it from JS. That means that the only possible places to exploit are bugs in the JIT, something that exists as well for JavaScript.

Even WASM gets bindings to the DOM, it's surface area is still smaller as Javascript has access to a bunch more APIs that aren't the DOM. For example, WebUSB.

And even if WASM gets feature parity with Javascript, it will only be as dangerous as Javascript itself. The main actual risk for WASM would be the host language having memory safety bugs (such as C++).

So why was Java and Flash dangerous in the browser (and activex, NaCL).

The answer is quite simple. Those VMs had dangerous components in them. Both Java and Flash had the ability to reach out and scribble on a random dll in the operating system or to upload a random file from the user folder. Java relied HEAVILY on the security manager stopping you from doing that, IDK what flash used. Javascript has no such capability (well, at least it didn't when flash and Java were in the browser, IDK about now). For Java, you were running in a full JVM which means a single exploit gave you the power to do whatever the JVM was capable of doing. For Javascript, an exploit on Javascript still bound you to the javascript sandbox. That mostly meant that you might expose information for the current webpage.


Replies

JoshTriplettyesterday at 9:43 PM

I think even when WebAssembly has access to every API that JavaScript does, it's still architected in a way that I think is less likely to lead to sandbox escapes. The thing doing the sandboxing doesn't have the full complexity of a programming language; some of that complexity lives either in the compiler or inside the sandbox. Some things that would be vulnerabilities in JavaScript become "it rather involved being on the other side of this airtight hatchway" problems in WebAssembly.