Hacker News Reader

Comment by throwaway81523 | Hacker News Reader

Write once run anywhere sounds like Java of the 1990s ;).

It's very similar. If Java had had a good sandbox model and not shipped with a large runtime available to all applications, from the beginning, there would be no reason for WASM to exist.

WASM is like Java bytecode without access to the Java standard library (like, no `java.lang.String` or even `java.lang.Object`... just the primitives).

But it has a mechanism to call "host" or "imported" functions and to use linear memory (an array of bytes which can be shared with other modules and the host), which is how it actually does anything useful.

I can imagine a version of Java that works like this as well, actually, I wonder if there's ever been anything like that?

Once the GC proposal lands, letting the host and application interact through object graphs, won't that bring back most of the same perennial security problems that Java suffered from?

Java's perennial security issues was that the sandboxing mechanism was implemented in Java in the same VM as it was trying to sandbox... then they added reflection. They couldn't plug all of the holes that could let you get a reference to the security management objects and go to town on them with reflection.

> Once the GC proposal lands

"Once".

That GC proposal isn't anywhere close to landing. It's making progress, but it's the "Zeno's paradox" kind of progress where the feature seems further away the more they work on it. I wouldn't be surprised at all if it still wasn't supported in browsers in 10 years.

WASM security story is sales talk, as anyone that understands pentesting is aware of.

I'd be interested in hearing more about this if you can point to some resources.

You can start here,

"USENIX Security '20 - Everything Old is New Again: Binary Security of WebAssembly"

https://www.youtube.com/watch?v=glL__xjviro

Then there are the issues that since WebAssembly doesn't prevent memory corruption, while RCE attacks or sandboxing breaks are not possible, by producing memory corruption, it is possible to eventually trigger alternative code paths that wouldn't be possible in normal circumstances.

A contrived use case would be to validate a user with higher credentials that they are supposed to have, in a WASM based security module.

Then since the external calls from the module are configured from the runtime, one can do man on the middle attacks on the functions being called from the module, thus access data that it wasn't supposed to be made available in normal cases.

And I bet that when the hacker community starts having fun with WebAssembly, as much as they have had with other bytecode formats, more issues will be found.

Thanks!

It does, but so do interpreted languages and the many compiled languages with different compilation targets.

It's less of a problem in 2021 than it was in 1995.

Sure, its the JVM, but open from the start, native in major browsers, and at a time when a popular choice for desktop development is “wrap a browser in a layer providing access to OS services”.

With the caveat that Electron is basically Windows 98 Active Desktop, and if we forget about Mozilla boycotts against CodeAlchemy and PNaCL.

Ironically, those boycotts are now meaningless given Chrome market share, including Electron.

It's very similar for sure, but it's worth nothing how this is different. WASM is much more accessible as it doesn't require additional downloads or tooling. It also supports a wider range of languages. I can take my Qt desktop application written in C++, run it through emscripten, and have it running in Firefox or Chrome in just a few minutes. Instead of having to build and release binaries for Linux, Windows, Mac, and Android, I can make a single WASM build, host it on my website, and run it anywhere. It's honestly incredible

Just like the Common Language Runtime.

Which always worked quite fine on the server side.

For desktop use, it just never had a good GUI API.

Reply on news.ycombinator.com