Wasm is an exception. It’s designed from the ground up to have an extremely simplistic model of execution that prevents common exploits like buffer overflows and such. The WASM runtime only exposes “safe” things and at an incredibly low level. Everything has to be built on top of these abstractions. The JVM is not architected the same way, the VM has a bunch of APIs exposed to it and you have to attempt to constrain those down to make a program secure. WASM starts from a secure by default position and you grant it capabilities as needed to accomplish the task. If all you need is to take in a string, do some computation, and output a string, then you can run a WASM module with zero disk or network access whatsoever, no ability to integrate with processes, environment variables, or anything else on the system. Trying to run a program on the JVM or CLR but prevent it from reaching out of itself by blacklisting certain functions or something is an exercise in futility.
WASM was designed before spectre happened, so no it's not the exception. In-process sandboxing cannot be securely designed anymore. You can endlessly chase security exploits with increasingly expensive and convoluted workarounds, but that's about it.
> It’s designed from the ground up to have an extremely simplistic model of execution that prevents common exploits like buffer overflows and such.
So is the JVM and CLR and dozens of prior runtimes for that matter.
WASM for guests is mostly a security regression as all the design focus was on protecting the host. Things in the runtime got thrown under the security bus (such as no ASLR)
> The JVM is not architected the same way, the VM has a bunch of APIs exposed to it and you have to attempt to constrain those down to make a program secure.
You're confusing concepts here. The JVM bytecode runtime has very few APIs and WASM has no inherent requirement on being minimal or capability-based. WASI, which is what's being used here, has neither of those design attributes, for example. It's just regular POSIX apis. No permission system + massive API surface, yet still WASM all the same
The approach is the same in both cases - find an exposed API surface with a privileged implementation, find some way to confuse it, exploit.
In a few cases there were JVM exploits that weren't based on that approach, almost always involving reflection or JIT compiler bugs.
The people saying WASM is easier to sandbox than the JVM are sort of half right and half wrong. The hard part of sandboxing is exposing safe APIs to the sandboxed code. WASM solves that by simply not exposing any APIs at all. This essentially punts the sandbox construction to the user and will allow WASM vendors to claim a good security track record, which they will get by not doing very much.
On the other hand, the OpenJDK guys are retreating from providing any sandbox at all and are taking it out of new Java versions. So you'll end up with mandatory exposed APIs that don't even try to be safe.
Neither approach is really all that great if what you want is the ability to run a useful set of normal-ish programs in a safe way. GraalVM has its own sandboxing features which look like a decent compromise, and you can still use process or VM sandboxing on top.
