If you are running untrusted code in Node, subtle JIT bugs are probably the least of your problems.
The answer is they are all vulnerable, just because of problems like this. Any user code (js in this case) is untrustworthy, and everything has js extensions. What’s the safe way to run user JS? Running v8 in its own somehow separately limited process maybe is what I think people do.
I agree; "trusting" third-party/remote code or not frankly went out the window with the bathwater including baby when we moved on to Web "JavaShit" 2.0, or was it 3.0.
Feels like we're in a worse security hellhole than we ever were with Flash or ActiveX back in the day, frankly.
Flash and ActiveX were proprietary technologies that often required users to install plugins or additional software on their devices. These plugins operated with high levels of access to the system, which made them a significant security risk. They were notorious for being frequently exploited by attackers as a way to run malicious code on users' machines.
In contrast, JavaScript is a core part of the web and is executed within the browser in a sandboxed environment. This means that JavaScript operates with limited access to the system's resources, reducing the risk of system-level security breaches.
Flash (and probably ActiveX) were also executed in a "sandboxed environment", including "limited access to the system's resources". All 3 have (or well, had, in the case of Flash and ActiveX) regular vulnerabilities - including JavaScript. JavaScript is not any better than Flash or ActiveX and I really don't understand why people pretend it is.
BTW, Flash was definitely a core part of the web in its heyday, too.
ETA: Oh, and Java was also executed in a sandbox (and a virtual machine!) and had plenty of vulnerabilities back when applets were a thing.
At least with Flash, ActiveX, and Java you could choose not to install them and most sites would continue working. For JavaScript you have to install (and trust) some third party extension to block it and then no sites work...
IIRC, the main issue with ActiveX was that it did not execute in a sandboxed environment, unlike Flash and Java. With ActiveX, all you had was a cryptographic signature saying it came from a trusted publisher; past that, the full Win32 API was available, with complete access to the operating system.
As I understand it there were weird pockets where organisations went hard in to activeX. IIRC it was used heavily by the South Korean government, and a lot of internal corporate intranet projects for all sorts of things.
That obviously caused massive problems a few years later when Microsoft tried to discontinue activex and make IE/Edge a normal web browser.
> JavaScript is not any better than Flash or ActiveX and I really don't understand why people pretend it is.
Because it is. Both of those were hard to use without crashing the browser - the primary selling point for Chrome originally was that it used process sandboxing and so when Flash crashed you wouldn’t lose every open window - whereas what we’re seeing now are complex attacks requiring considerable investment finding ways to get around the layers of precautions. It’s like saying that there’s no difference between leaving your money under the mattress and putting it in the bank because banks still get robbed.
The case of user provided extensions definitely falls a lot closer to the supply chain threat model.
The trust we give to random dependencies like that is quite arguably unwarranted to a large degree, but it doesn't mean the code isn't trusted.
It is how these conversations always go:
There’s a hole in the sandbox.
If you were trusting the sandbox, you were already doomed.
Nobody validates their code well enough to trust it. (we are here)
The ecosystem and industry is just irreparably damaged.
What am I supposed to do about that?
Non-solutions, because it is an impossible problem to actually fix
It does not directly affect servers if one rejects your rather broad definition of untrusted, but does indirectly.
> I’m pretty sure untrusted code means code you can’t trust, which includes any code that you haven’t either analyzed yourself or put through some sort of institutional review with auditable sign-offs.
That is so broad that very people are running trusted code. You would need to ensure your entire stack down to the firmware it runs on had been analysed.