Executing code written in any language -- dynamic, static, compiled, interpreted -- would be problematic here.
> That service loads the low level antivirus engine, and analyzes untrusted data received from sources like the filesystem minifilter or intercepted network traffic.
Forget JS. Do not load or execute code from untrusted sources in an unsandboxed environment with system permissions. This is about capabilities, not syntax. If your main takeaway is, "they should have used a C interpreter instead", then you have entirely missed the point.
But how many C/C++ engineers would think to design a system that runs a min interpreted code, vs JS ones? The take isn’t as bad as you think.
Multiple people, in this very thread, including you[0]. And apparently at least one Avast engineer and their upper management.
I'll requote/paraphrase another commenter[1] down-thread: it wasn't JS devs who wrote a custom interpreter inside a privileged C/C++ program. It was a C/C++ developer who thought, "I can handle this."
It's very important when calling out security failings to point out the real failing. If people are reading this and trying to take away security advice, I don't want their takeaway to be, "so my custom LUA interpreter is fine."
So, I did what any sane devops engineer would do; I throttled the CPU use limit for its cgroup in the systemd service file. Now no more scans.
Except now the UI wouldn't load. Couldn't figure out why. Just an empty white window. Turns out, it's running a node.js server and the whole UI is rendered in HTML/CSS/JS, but because of that it was so non-performant that the UI would effectively not render at all if it couldn't slam your CPU.
I can't think of any native-code, native-widget, control-panel-type UI that would completely fail to render the entire window at all if limited to 10% CPU time, but hey, here we are.
> Turns out, it's running a node.js server and the whole UI is rendered in HTML/CSS/JS, but because of that it was so non-performant that the UI would effectively not render at all if it couldn't slam your CPU.
So was it the naive approach to system scanning, or the web-based UI that was the problem? Because there are some performant desktop applications using web rendering, like VS Code. Though I'm not sure how VSCode would behave if limited to 10% of CPU, because that's kind of a weird scenario.
This is essentially how antivirus software works. Every one of them packages an emulator to execute malicious binaries.
I'd say the number one thing stopping C++ devs from running eval'd C++ code is the lack of a std eval, and that's probably it.
Frankly, I am far less concerned with the js interpreter than I am the rest of the codebase.
http://computervirus.uw.hu/ch11lev1sec4.html
https://www.blackhat.com/presentations/bh-europe-08/Feng-Xue...
http://joxeankoret.com/download/breaking_av_software_44con.p...
To be honest though, in the modern world, picking a stable compiler like GCC is a good enough choice for life - this isn't the 90s where you might have to dumpster dive to find copies of that specific borland compiler your company decided to tailor their code to.
(edit: All the above holds until you start making assumptions about uninitialized memory, at that point you're really in trouble and, honestly, C++ really should be better about preventing you from using dirty memory)
void doDangerousStuffIfAuthorized(AUTHORIZATION* authorizationPtr){
AUTHORIZATION authorization = *authorizationPtr
if(authorizationPtr == null || !isValid(authorization)) return;
doDangerousStuff();
}
I think this makes it worse.
What reason is there to even have such an interpreter in a highly privileged process?
Benchmarks. It's faster if you don't push all the scanned data through a process boundary.
FFS, even display drivers don't run with full system privileges anymore.
And BTW, this is why WebAssembly runtime on the server is a big deal. Being able to painlessly run any untrusted code from "nonsafe language" in a sandboxed environment.
Also, if you read it correctly, Avast is running "wild" Javascript in a custom privileged VM (potentially written in C++)
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.
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...
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?
I meant maintained by app developers who include the runtimes, not the runtimes themselves.
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.
Serious question, what are reasons to use JS in non-web contexts, apart from developer familiarity?
V8 on the server has a very nice eventloop that's very easy to leverage for high performance while avoiding horrifying overflow issues and fits well for a large majority of web request/response patterns while still offering significant developer speed.
Some even find it fun to bend something that isn't meant to be bent.
I never said that.
More than that, at least last time I checked, V8 is really fast. It is many times faster than the usable Python implementations, or practically any other memory-managed runtime. Only luajit seemed to sit in the same ballpark when I pulled up the shoot-out a couple years back.
I personally hate all of these facts, but sometimes, they really do mean that prioritizing JavaScript, or at least something that compiles down to JavaScript, is the best choice.
Wait, hold on: you can usually run C on most devices.
I take it you're not a big fan of JS? That's a lot like saying your not a fan of hammers. Maybe you aren't good at using them, maybe the noise scares you; maybe you think hammer wielders are all idiots and the only smart people are shovelers. It's a tool, it works better in some situation, worse in other.
Low effort <insert language here> developers are everywhere. Lol. Please just stop. Any language is a bad language if used poorly. Literally, JS is just as bad as C++ in the hands of the incompetent.
AvastSvc.exe is not the place where you need programming 'at scale'.
Said who?
> You can't have an entire industry push this terrible ecosystem, then expect security companies to miss out on the fun.
I would expect most security experts to push you to use JavaScript instead of C++, since the former will protect you from a number of rather common security issues in the latter…
> Locating and hiring C++ engineers at a scale is something that has become very, very difficult.
Is it really that hard? Here, I can help: I know C++, and I'll be graduating soon. Hire me ;)
Even if you did all that, odds are that you still don't know C++.
Yeah this is part of the reason why I wont even try to learn the language
This isn't some MIDI parser logic, it's an entire JS interpreter that can parse DOM elements! How in Earth did this even get pushed out to a release? Did we learn nothing since the last time [1]?
1: https://bugs.chromium.org/p/project-zero/issues/detail?id=12...