| People have previously shipped JS runtimes on top of .NET and the JVM. It's not a question of 'who writes the GC', it's more fundamental. If you JIT your JavaScript down into raw native code that bangs rocks together to dereference pointers, you need to make sure your generated code handles pointers correctly. You need to make sure to get all your bounds checks right, etc. Sure, the JVM could somehow have a 30-year-old bug in its array bounds checks. But if you're JITing javascript to an IR that doesn't have raw pointers and instead uses strongly-typed object references and bounds-checked arrays, you have automatically closed off a whole category of defects. At the point where you're saying "sure, but what if the JVM messes up array bounds checks?" you might as well be asking whether v8 can really afford to rely on read-only pages and guard pages for its security sandbox. What if the kernel is broken? I mentioned type confusion attacks in particular because they're a class of attack that generally doesn't work against java or .net applications because values can't change type arbitrarily during execution. Local variables and parameters have known types, object type casts are checked, array elements are typechecked before being stored, etc. Obviously you pay a cost for this, and if you have threads the ABA problem rears its head, but JS is single-threaded by design. Between hosting JS on the JVM or in WASM, WASM is probably a safer choice since it's such a constrained sandbox. But the JS runtime you're running inside of the WASM sandbox is still built in C, banging rocks together to dereference pointers. Hopefully you're running a modern security-hardened JS runtime inside that sandbox, and you haven't turned off all the security mitigations thanks to wasm's lack of page protections. |
Yes. it is.
That's literally the whole point.
The bugs in this post are bugs in the runtime - the implementation of the Gc, the implementation of the object metadata.
If you build your JS engine on top of a safe/managed environment the attacker is not interested in attacking logic bugs in your JS engine, they're target the runtime. All you have done is move the problem from "the attacker exploited bugs in the JS runtime, how do we prevent those?" to "the attacker exploited bugs in the Java (or whatever) runtime, how do we prevent those?". The problem is that at some point any safe language (java, rust, or even - as here - javascript) has a runtime that has to be implemented in an unsafe environment, and that is what is being attacked.
The JVM and .NET are not magical, they have the same bugs - albeit with significantly less hardening and mitigations - as JS engines.
What you are saying is that the JS engine should be written in Java (or whatever) so it's safe. But now how do you fix the JVM? Maybe rewrite that in C#/.NET? But then you have to fix the .net VM? Maybe rust? of course then we need to ensure that's safe so we should run that all under wasm. Of course that means your back at the JS engine you started with.