[LeoNatan25]

Your expectation makes no sense. Popular JS VMs have huge attack surfaces, and are prime candidates for gray and black market vulnerability hunts. They are often not maintained, thus once a vulnerability is discovered, the entire app is compromised. In the case of a highly-privileged process, this can be catastrophic.

Contrast this with tailor-made, slim and well tested C++ code. And yes, I do expect security companies to have well-written and well-tested code.

[detaro]

> And yes, I do expect security companies to have well-written and well-tested code.

Your expectation makes no sense, given the vulnerabilities we've seen in AV software in the past decade.

If they insist that executing suspect JS is a good idea, they a) probably should use an established interpreter unless there's good reasons not to and b) not run it privileged.

EDIT: Avast appears to have deactivated this now: https://twitter.com/avast_antivirus/status/12376853435807539...

[saagarjha]

> Popular JS VMs have huge attack surfaces

No, not really? Depending on the browser they have generally have a small-to-medium attack surface. Yes, they can JIT, but often they can't do much else.

> and are prime candidates for gray and black market vulnerability hunts

Because they are remotely exploitable, nothing more.

> They are often not maintained

The world's deepest pockets and countless hours from the world's smartest minds go into maintaining them…

> once a vulnerability is discovered, the entire app is compromised

Not in modern browsers.

> In the case of a highly-privileged process

Oh good, so not the JavaScript process, right?

[LeoNatan25]

How many vulnerabilities have existed in Electron apps, sandboxing and all?

I meant maintained by app developers who include the runtimes, not the runtimes themselves.

[saagarjha]

> How many vulnerabilities have existed in Electron apps, sandboxing and all?

Significantly fewer than you'd find in a comparable C++ application, probably, and with much less effort put into securing things like "if I index into this array am I allowing for an arbitrary write primitive" and "can I safety use this object without giving an attacker code execution". Electron bugs tend to be of the sort like "oops, we can load a file from the filesystem because we forgot a string check", and C++ bugs are "that, but with the other things I just mentioned".

[LeoNatan25]

> probably

Based on what? On C++ you have complex systems with difficult code to get correctly. With Electron, you have terrible chat apps that take 1GB of memory to display a few chat bubbles that allow remote execution into machines running them.

The data to compare the two is just not there to assume anything like you just did. Meanwhile, electron apps have proven quite insecure, despite not being able to allow arbitrary write primitive by indexing into an array.

[_bxg1]

> Popular JS VMs...are often not maintained

The V8 engine, in 2020, is one of the most actively-maintained software projects of any kind. And (for better or worse) nearly everyone who needs a JS engine uses that one. This includes - among others - Chrome, NodeJS (which means Electron too), and now Edge. The only major outliers I can think of are JavaScriptCore (iOS/Safari) and SpiderMonkey (Firefox).

The sin committed by Avast was rolling their own version of something, as a less-than-massive-company, when the state-of-the-art implementation is OSS. That has nothing to do with JavaScript the language. You're commenting on things you clearly know nothing about.

[leshow]

Id say it makes a lot of sense. You're comparing a memory unsafe language with a safe one.

[LeoNatan25]

The runtimes are also written in “memory unsafe languages” (C++). The runtimes bring a whole lot more code than if you wrote own tailor made code, meant to do something specific, in “memory unsafe languages”.

[saagarjha]

Yes, but the runtimes usually have a large amount of time and security effort invested into them.

[armitron]

This is not correct in my experience. I think it's more apt to say that security effort has mostly been spent around sandboxing and related technologies which is really an admission that there is no way to secure the JS VMs in themselves. The best engineers in the world can't do it. Maybe that will change if they move to safer languages, but so far nobody has done that.

Therefore when you see an exposed unsandboxed VM, you instantly know it's critical issue.

[saagarjha]

Writing secure C++ is quite hard, even for the best engineers in the world. However, that absolutely does not mean that your handcrafted C++ code is more secure than JavaScript running a virtual machine that is written in C++. The sandbox exists as another layer of defense, not because the code is inherently more insecure. (Also, it's usually because JavaScript virtual machines evaluate untrusted input, which is something that has been shown to be notoriously difficult to secure against in general.)

[paraboul]

Can I invoke my @pcwalton card here? :-)