[jeltz]

As much as I am tired of the crappy code produced by some JS developers this time they are innocent. If you had read the article you would have known that the JS code executed here is JS found on the Interent, not any JS written by Avast. The bugs are in Avast's C++ code (or possibly C).

[JdeBP]

The bugs aren't in the code, and this whole subthread begun from what LeoNatan25 wrote is a tangent. The bugs are in the design, of downloading programs from random untrusted anybodies on the World Wide Web and running them, indeed of downloading programs from random untrusted anybodies on the World Wide Web and running them with elevated privileges. In order to test whether they are malicious, no less.

[saagarjha]

> If you had read the article you would have known that the JS code executed here is JS found on the Interent, not any JS written by Avast.

I think this makes it worse.

[SahAssar]

Yes, but it also means that this is not implemented because of "low-effort JS developers".

[LeoNatan25]

I have read it. It's not clear what code runs inside the interpreter.

What reason is there to even have such an interpreter in a highly privileged process?

[GoblinSlayer]

>What reason

Benchmarks. It's faster if you don't push all the scanned data through a process boundary.

[benmmurphy]

If the interpreter was running code written by Avast then it wouldn't be a security issue. Having an interpreter running code you have written vs writing the code in C++ is not necessarily better or worse from a security point of view.

[tremon]

Highly disagree here. Javascript's DOM parsing functionality has but one purpose: presentation manipulation, i.e. rendering. Having something like that running as SYSTEM is a security issue in itself, regardless of where the code comes from.

FFS, even display drivers don't run with full system privileges anymore.

[mosdl]

JS has no DOM API, browsers provide JS an API to use. Plus DOM had nothing to do with rendering, it's just tree manipulation APIs.

[saagarjha]

Generally the interpreter is probably better, once you have enough memory-managed code that it outweighs the number of vulnerabilities in your native code by virtue of its significantly lower bug rate.