15 ms·
I don't expect much from anti-malware companies, but this is one of those moments that made me absolutely dumbfounded that someone actually thought embedding an
by joshumax 7y ago
I don't expect much from anti-malware companies, but this is one of those moments that made me absolutely dumbfounded that someone actually thought embedding an entire un-sandboxed JS engine with SYSTEM privileges was in any way a good idea. I actually had to get out of bed, open IDA, and start a Windows VM just to check that this wasn't some sort of elaborate hoax!
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=1252&desc=5 https://bugs.chromium.org/p/project-zero/issues/detail?id=12...
- saagarjha 7y agoPsst…there's a Linux harness to load the DLL.
- LeoNatan25 7y agoBecause low-effort JS developers are now everywhere. Just as JS should not be found in the server yet is now prevalent, JS is now finding its way into other places where it shouldn't be. You can't have an entire industry push this terrible ecosystem, then expect security companies to miss out on the fun. Locating and hiring C++ engineers at a scale is something that has become very, very difficult.
- jeltz 7y agoAs 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).
- saagarjha 7y ago> 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 7y agoYes, but it also means that this is not implemented because of "low-effort JS developers".
- LeoNatan25 7y agoI 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?
- benmmurphy 7y agoIf 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.
- saagarjha 7y agoGenerally 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.
- tremon 7y agoHighly 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 7y agoJS 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.
- GoblinSlayer 7y ago>What reason Benchmarks. It's faster if you don't push all the scanned data through a process boundary.
- JdeBP 7y agoThe 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.
- paraboul 7y agoI'd expect server-side JS code running on popular VM (v8, spidermonkey) to be safer than custom C++ (sandboxed vs running on the bare os). 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++)
- LeoNatan25 7y agoYour 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.
- paraboul 7y agoCan I invoke my @pcwalton card here? :-)
- deleted 7y ago[deleted]
- detaro 7y ago> 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/1237685343580753925 https://twitter.com/avast_antivirus/status/12376853435807539...
- leshow 7y agoId say it makes a lot of sense. You're comparing a memory unsafe language with a safe one.
- fetbaffe 7y agoLove when the C++ dev enters the debate and claims with a straight face that security vulnerabilities is problem in other languages.
- IanSanders 7y agoIt's not about C++, it's about selecting a more appropriate tool that JS. JS is often used only because the developer knows nothing else. What's even more ridiculous, often JS is not even the easiest route. Serious question, what are reasons to use JS in non-web contexts, apart from developer familiarity?
- paraboul 7y ago> @paraboul is on point: JS is often used only because the developer knows nothing else. I never said that.
- IanSanders 7y agoApologies, I misinterpreted. Redacted
- saagarjha 7y agoJavaScript is one of the fastest scripting languages, for one. It often has pretty decent bindings to native code as well.
- cookiecaper 7y agoJavaScript is the only thing that you can really run on any semi-modern device. TVs, phones, laptops, desktops, servers, the only thing you can expect to execute on all of them is JavaScript. If you write your core libraries in JavaScript, you'll have that much less to worry about re-implementing and maintaining in something else. You'll have flexibility to potentially execute the same code on either client or server, phone or desktop. There are situations where that's pretty useful. 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.
- sk5t 7y agoThis is more like a lazy or deeply ignorant use of running a process as root and reflects on the recklessness of the system designer, and not on whatever that process happens to be.
- saagarjha 7y ago> Just as JS should not be found in the server 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 ;)
- armitron 7y agoIf you haven't spent substantial amounts of time (personal estimate > 10 years) working with C++ writing production code , you certainly don't know C++. Even if you did all that, odds are that you still don't know C++.
- saagarjha 7y agoOk, so I lied, I don't really know C++ because nobody really knows everything about C++. But I have written production C++ code (some of which is used by most of the people here, including you…) so ¯\_(ツ)_/¯. Anyways, this is veering off-topic, so if you or someone else would like to discuss your hiring woes and/or would like to test whether I really know C++ my email's in my profile; I'd be happy to talk to you there.
- non-entity 7y ago> If you haven't spent substantial amounts of time (personal estimate > 10 years) working with C++ writing production code , you certainly don't know C++. Yeah this is part of the reason why I wont even try to learn the language
- saagarjha 7y agoDon't let them scare you away from learning it; you can absolutely write C++ to a useful capacity in much less time than that.
- 7y ago
- rmrfrmrf 7y agoI don't think JS devs are the ones embedding JS interpreters into binaries.
- techntoke 7y agoEver heard of Electron?
- danShumway 7y agoThat is a really bad take. 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.
- LeoNatan25 7y agoI agree with you that no interpreter should be running there. It’s bad design. 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.
- danShumway 7y ago> But how many C/C++ engineers would think to design a system that runs a min interpreted code 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." [0]: https://news.ycombinator.com/item?id=22545385 https://news.ycombinator.com/item?id=22545385 [1]: https://news.ycombinator.com/item?id=22545945 https://news.ycombinator.com/item?id=22545945
- LeoNatan25 7y agoWhere did I talk about having interpreted code?
- 7y ago
- otabdeveloper4 7y ago> Locating and hiring C++ engineers at a scale is something that has become very, very difficult. AvastSvc.exe is not the place where you need programming 'at scale'.
- asveikau 7y agoI actually agree with your conclusions, however, if they had dropped privileges before running javascript it would be worlds and worlds better. Whoever bootstrapped the C parts should have known this.
- blattimwind 7y agoThe problem here is actually that the scanning engine is running as SYSTEM in the first place. Whether having a JS engine/emulator in there is a separate matter. As usual, "endpoint security software" is very poorly engineered. Keep in mind that this is a common pattern among vendors; though some are even worse (e.g. Symantec used to do this directly in kernel space).
- Der_Einzige 7y agoPart of it is that C++ is poorly taught in most universities. Even if you do get an education in C++, try using any of the modern features like smart pointers on your homework. Your teacher most likely will give you a poor grade.
- boomlinde 7y agoIn this case, the interpreter is included for analysis of JS code and was seemingly custom made for that purpose, not to leverage JS developers, so your point doesn't apply here specifically.
- craftinator 7y ago> Because low-effort JS developers are now everywhere. 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.
- thrownaway954 7y agowas it intentional that the bug you linked to is assigned and owned by this same dude?
- currysausage 7y agoTavis Ormandy has been dismantling AV software, one after another, for some time now.
- tinus_hn 7y agoBe sure to keep on complaining about Apple not allowing interpreters on iOS though