Hacker News Reader

Comment by olliej | Hacker News Reader

The underlying problem is what the threat model was - in Java/JVM a significant amount of effort was put into addressing "what if the byte code itself is malicious", with the core applet VM having quite a lot of power over the system - e.g. file I/O, GPU access, etc.

View on HN

Actually only when one did not bothered to spend any effort with Security Managers, Classloaders separation and JAAS.

All the tools were there.

WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking.

> WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking.

Unsafe applications won't ever be magically safe when compiling them to WebAssembly. Neither would this be the case when compiling to Java bytecode - if this was possible at all.

IMHO WebAssembly is a compilation target and therefore not the right layer to solve this. This is the responsibility of the language or the specific application. If you want to solve this in WASM, I predict you couldn't just compile all different languages to WASM anymore without significant changes to the codebases. If this would be feasible at all..

Rewriting those huge C/C++ codebases is simply not an option, new applications can be written in safe languages and then compiled to WASM.

Java bytecode requires bound checking and null pointer validation, as per the JVM specification.

CLR proves the contrary, by having C++ support, with the difference between safe Assemblies (where typical memory corruption opcodes are not allowed, compilation via /CLR) and unsafe Assemblies, where WASM like opcodes are allowed.

To load an unsafe Assembly, the host has to explicitly allow it.

Similar examples on IBM and Unisys language environments, e.g. on ClearPath, the admin must allow the execution of binaries tainted with unsafe code.

WASM has bounds checking on the linear memory as well.

Care you point it where in the standard, because I don't see it on the memory access opcodes.

> A linear memory is a contiguous, mutable array of raw bytes. Such a memory is created with an initial size but can be grown dynamically. A program can load and store values from/to a linear memory at any byte address (including unaligned). Integer loads and stores can specify a storage size which is smaller than the size of the respective value type. A trap occurs if an access is not within the bounds of the current memory size.

In general the groups doing standardization for browser APIs and runtimes don't seem to care much about whether web applications are compromised, only whether the browser or host platform are compromised. It's reasonable for the latter two to be priorities, but when we're talking about huge gmail-tier applications running unsafe C in a sandbox that have access to All Your Important Data, we're going to massively regret letting type safety and other features slide.

> ...we're going to massively regret letting type safety and other features slide.

PHP is memory safe, and yet is a larger source of data breaches and security bugs than C by (rough guess) an order of magnitude.

C is not the bogeyman you're looking for.

PHP may be memory safe but the shitload of poorly written C extensions enabled by default on all hosts that shipped with the distribution from 1995 to 2010 sure as hell weren't.

C extensions wasn't the part of PHP that broke the amateur Internet, SQL injections were.

Using the WASM GC part instead of lieanr memory will solve that, right? I know it's not a possibility for all programs, but overall, it'll help?

Not at all, because a large majority of applications being ported to WASM are written in C and C++, with all security caveats it entails.

Garbage Collected implementations of C and C++ do exist, and only thing that their GC fixes is use after free.

Web browsers also have all those things.

Yup, and work super aggressively to restrict it -- back when the JVM was supported, a large amount of the browser sandbox had to be extended to support the arbitrary behavior of the JVM, subsequently moving it out of process still required providing unrestricted access to OS components that you would rather they didn't.

At a very basic level it can be summed up with: the JVM approach to GLSL was to just throw it at the GPU, whereas the browsers worked on restricting WebGL to a super constrained subset (this was my fault, but is the correct thing to do :D )

By the time browsers were considering out-of-process plugins, the JVM was already thoroughly eclipsed by Flash. I think Flash's general brokenness (over half my browser crashes/hangs were caused by Flash) was the main motivation for out-of-process, not JVM's hugely broken sandbox.

Applets were eclipsed because of their monumentally expensive launch requirements - both time and memory.

The applets also made it hard to do a bunch of the simple games that were super popular - flash included a large amount of multimedia functions built in, and an editing environment that was geared towards interactive design.

The reason java took so long to move out of process was because the java<->browser bindings were unique to java, it did not use any of the normal plugin apis, and expected a lot of direct linkage to the host system.

Reply on news.ycombinator.com