With most types of software, if you're stuck with C/C++, you want to keep the development to a high standard where there aren't any bugs like this. But anti-virus software is unusual in that it needs to handle malicious input of an unusually wide variety of file formats, which makes completely eliminating file-format vulnerabilities basically unfeasible without some sort of broadly-applicable fix.
That fix could be a memory-safe language, or it could be sandboxing. But the assumption should be that for any antivirus product which does its file-parsing in C or C++, and which doesn't sandbox is scanning engine, there's going to be at least one critical vulnerability in the scanner. Bitdefender is still unsandboxed, so fixing this particular vulnerability is only of limited use; there are almost certainly other, similar vulnerabilities in it, so users running it are vulnerable to anyone with the resources to find one.
AV companies have mostly gotten away with this sort of thing in the past, because individual AV scanners tend to have low enough market share that they aren't as desirable targets as web browsers. But Windows Defender recently broke that trend by being present on every Windows system, and having a critical vulnerability, so now there are a lot more researchers looking at unsandboxed AV scanning engines and finding problems.
The fix could be a memory safe language in theory, but in practice it's very unlikely.
A lot (all?) of the parsers for various formats are written in C or C++. Two small exceptions: I've seen that there's a Rust image library available, however it's part of another larger project and has almost zero documentation or comments. There's also a Rust lib for zip files, but it wraps a significant amount of C.
It looks to me that Mozilla aside the industry has given up and decided to sandbox.
Considering the amount of crap code out there, it's understandable. I like to read the details about vulnerabilities when updating Ubuntu. Most of those could be easily avoidable in C++ if one knows how to write secure code. The fixes are usually adding some checks, an extra if, an initialisation, etc - treating the symptom.
e.g: the Bitdefender team missed that a 64 bit uint was passed to a function taking a 32 bit parameter. They likely have all casting warnings disabled - a lot of C library code spews a ton of warnings.
"Fixed" by changing the parameter to 64 bit.
Have to mention SaferCPlusPlus[1] here - basically a memory-safe subset of C++ with (fairly) low migration cost. For example, here[2] is an open source png encoder/decoder that was ensured to be free from buffer overflow vulnerabilities via automated (partial) translation to SaferCPlusPlus.
Technically, you would need to unambiguously define what you mean by "safe" and "Rust", but in the way that I think you mean it, the answer is essentially yes. "SaferCPlusPlus" does not refer to "modern" C++ programming practices that can help avoid many traditional classes of bugs. It, in theory, refers to the avoidance/prohibition of any C++ element that can access unallocated/deallocated or uninitialized memory. That means for example, no native pointers (including the implicit "this" pointer in member functions), references, arrays, unions, etc.. It also means no unsafe standard library elements like std::vector, std::array, std::shared_ptr, std::unique_ptr, etc.. In order to make this practical, there is a SaferCPlusPlus library that provides largely compatible (memory) safe substitutes for the most commonly used of these elements.
The implementation of SaferCPlusPlus as a language/dialect is not yet complete. For example, there is not yet a proper compile-time "enforcement" tool to verify that your code is actually free from unsafe elements. But as a programmer, you basically know what those potentially unsafe elements are, and the SaferCPlusPlus library already makes it practical to write C++ code that avoids the vast majority of them.
That said, I would say that, at the moment, SaferCPlusPlus is not a direct alternative to Rust. If you have the resources to do a rewrite of your project in Rust and memory safety is paramount, then that's probably the way to go. On the other hand, if you need a more expedient way to address code safety or have some other issue with using Rust, SaferCPlusPlus may be a more attractive choice.
Thanks for the link and the detailed explanation. This confuses me a bit:
> SaferCPlusPlus does not restrict the number and type of references to an object that can exist at one time (i.e. the exclusivity of mutable references)
and
> SaferCPlusPlus .. deals with this issue by having the pointer/reference itself "know" if its target dynamic object is still valid.
It sounds like this happens at runtime (reference counting?), as opposed to compile time. Do I understand that correctly?
Also, I see that there is the `access requester` type, are there any facilities like Send/Sync in Rust which guard against data races at compile time or runtime?
Well, the "scope" pointers, which roughly correspond to Rust's "non-mut" (i.e. non-retargetable) references and are generally the most commonly used pointer/reference type, don't have any run-time overhead. By their nature, as long as they exist, so does their target. You don't need a sophisticated borrow checker to ensure it.
"Mut" (i.e. retargetable) references, on the other hand, do require a borrow checker to ensure, at compile-time, that their target will outlive them. Since SaferCPlusPlus does not have a borrow checker (yet), you'd have to use "registered" pointers, which do have run-time overhead. But in practice, retargetable references are generally much less common than non-retargetable ones (particularly in inner loops), so there tends not to be much effect on performance.
SaferCPlusPlus does not yet have an exact analogy to Send/Sync. But as I understand it, those are basically just indicators that say "Trust me, this object is safe to send to / share with other threads." without any verification of the proclaimed safety. At the moment, SaferCPlusPlus does something functionally similar by providing the "TAsyncSharedObjectThatYouAreSureHasNoUnprotectedMutablesReadWriteAccessRequester" which basically allows you to make the same claim about the safe shareability of the object. (And has an unwieldy name to remind you of the seriousness of the claim.) Basically the rule of thumb is "Don't share any object that contains pointers/references/iterators (or is declared "mutable" in C++) or has any (non-static) member functions that return pointers/references/iterators."
Rust and SaferCPlusPlus maybe take different positions on whether sharing objects between threads should be encouraged with abandon, or done prudently and only as necessary.
Sorry, I don't think I was thinking very clearly for the last part. I think you're right, the missing Send/Sync functionality is one of the areas where SaferCPlusPlus is still lacking.
You're not wrong that Rust is "trusting" the developer. But in most situations this is the same as any developer claiming that they've written a thread safe type. Rust's type system just guarantees that you have declared these things to be true, which at a high level gives you a lot of confidence.
This is a bit of a broad brush. It assumes that all people always act with the best security hygiene.
I detest traditional AV as snake oil and realize that there is additional risk added by using AV, but it does have its place in many threat models, especially for those who are not internet+security literate.
AV will make those people who are not internet+security literate more vulnerable. There have been vulnerabilities found in all major anti-viruses, some of them were really bad. You're better off not using an antivirus. See for example: https://arstechnica.com/information-technology/2017/06/lates...
Staying up to date on your updates is the best advice you can give.
> AV will make those people who are not internet+security literate more vulnerable. There have been vulnerabilities found in all major anti-viruses, some of them were really bad. You're better off not using an antivirus.
I don't think you can reasonably defend this position.
Let's take a pessimistic guess at the efficacy of antivirus software and say it blocks 50% of the new malware generated in a given day. Now let's take a wildly optimistic stab at the added risk of using antivirus and say it increases your exposure by 1%.
Are you really saying that a 1% risk increase is too high a price to pay for halving your risk overall?
Don't get me wrong, there are all kinds of reasons for power users to bemoan antivirus. RCE vulnerabilities are certainly one, but even just day-to-day usability issues are a legitimate concern. The average user, though, is still statistically much safer with antivirus.
> Staying up to date on your updates is the best advice you can give.
The vast majority of attacks don't involve vulnerabilities, even counting events like WannaCry. It's mostly down to people clicking on things they shouldn't be clicking on. Keeping your software updated is important, of course, but absolutely will not keep you safe.
Oh this looks like a fun game. Let me try. Let's take a pessimistic guess at the efficacy of antivirus software and say it blocks 20% of the new malware generated in a given day. Now let's take a wildly optimistic stab at the added risk of using antivirus and say it increases your exposure by 35%.
Are you really saying that a 35% risk increase is an acceptable price to pay for a small reduction in overall risk?
You can't just pull numbers out of thin air to make your point.
Experience has shown us that antivirus software does not do what it says on the tin.
> You can't just pull numbers out of thin air to make your point.
> Experience has shown us that antivirus software does not do what it says on the tin.
Whose experience?
I built WildFire at Palo Alto Networks[1]. We analyzed a few tens of millions of new potential threats daily, including the VirusTotal firehose.
As part of our internal efficacy and competitive monitoring, we took the top 5 enterprise antivirus products and ran everything coming into WildFire through them.
The delta between ground truth and what the antivirus engines caught using only static scanning and emulation was about a third, i.e. better than the pessimistic estimate of half I threw out. (In the real world, antivirus actually does better because malware is easier to catch after it starts running.)
The danger of antivirus, on the other hand, is wildly overstated in this thread. A small fraction of attacks use vulnerabilities to begin with, and in the scheme of things, very few antivirus vulnerabilities have been found. 1% is just a nice, round number chosen for illustrative purposes; it's orders of magnitude greater than the real risk.
Now, this will surprise exactly no one who works in security, since most new malware is a minor variant of existing malware and exploits are relatively uncommon, but for the less experienced folks reading these comments, I implore you: Don't listen to people who say antivirus is useless or, worse, makes you less secure.
> The danger of antivirus, on the other hand, is wildly overstated in this thread. A small fraction of attacks use vulnerabilities to begin with
But AV vulnerabilities sit on the top of the attack class pyramid. They often are remotely executable, run with kernel privileges and do not require user interaction.
You can't lump that together that with malware that requires tricking a user into downloading an installer, clicking through it and granting it elevated privileges.
You're right of course, my point is that without some evidence you're just making up numbers to prove your point and any jerk with a keyboard (like say, me) can do the same thing. Thanks for providing some background to those numbers.
This Bitdefender vulnerability doesn't come with a PoC and is difficult to exploit due to DEP and ASLR---hooray for defense in depth! I've got a thousand nodes running Bitdefender in environments where malware runs rampant, and I'm not really that worried about someone coming after us through the scan engine. What I am going to do is make sure all my clients are up to date, which is really no different than my existing patch management activities.
If you're talking about WildFire, it's not an antivirus product and isn't relevant to this conversation beyond establishing the provenance of the data I've shared with you.
If you're talking about something else, I've stated that antivirus detects around two-thirds of new malware on any given day. In case it wasn't already clear, two-thirds is terrible.
Your claim is far more extreme, though. You said "You're better off not using an antivirus". That's wrong. Antivirus won't keep you safe, but you're still safer with it than without it.
If you're saying cookies shouldn't be flagged by antivirus, that's wrong. Cookies can be associated with malware in any number of ways[1], although grayware (especially adware), which antivirus also flags depending on configuration, is a more likely culprit.
1. Check out PyExfil, for example: https://github.com/ytisf/PyExfil. Cookies for data exfiltration. DNS controls on firewalls are there for similar reasons.
Antivirus software is fundamentally reactive in nature, not proactive, and I don't run antivirus software to catch novel malware. That's mitigated in other ways (which largely amount to good hygiene and disaster recovery planning).
Rather, I run antivirus software to prevent vulnerabilities due to human error and known threats, and in this regard it functions admirably. Think of it as one of the latter lines of defense in a multi-layer strategy. We are human; we trust our family, friends, and colleagues innately; and even the best of us makes mistakes. One tiny mistake, one shortcut---maybe not even by ourselves but by someone inside our circle of trust---and even security experts can end up running malware. Antivirus acts as a backstop, a last ditch defense predicated on the likelihood that the malicious code in question is well known.
I don't know where you got your numbers from, but I've run enterprise antivirus for about 15 years now. I haven't seen anything target the scan engine. I have hundreds of thousands of instances where someone ran malware and the scan engine caught it, sometimes even just using heuristic signatures. So you do you. I'm going to continue running it even though I know it's reactive.
Antivirus has it's place of course but they are not all created equal. There's a lot of marketing B.S. associated with AV products, especially consumer versions.
A lifetime ago I worked in IT support and AV was a constant pain point. For me it was a lot of energy wasted cleaning up PCs that were "protected" by the likes of Symantec and Norton. I hope the state of the industry has improved since then.
No, it makes them less vulnerable. I work on computers for some very tech illiterate people. They will regularly get more badware until I install an AV (generally avast! Free).
Let's forget about statistic. AV doesn't make your system immune from risks, but it's a good check. Perhaps going extreme, some vaccines are not 100% preventive (there are many that do). I download a file, run file check, and if I am still not convinced, I go to Virustotal to get more feedback. From experience there were a few malicious one passed by most of the AVs, because many AVs determine maliciousness based on same algorithms.
I get the idea that we should ditch an AV if vendor sucks at producing and maintaining the AV software, because that's literally inviting for a thief to stop by. You are better off reducing the risk exposure. But there is still a value to have one.
As with any software there are bugs. It just so happens Edge is shipped with Windows 10, and is also made by Microsoft. So should we give up on Chrome / FireFox / Opera because they also contain vulnerabilities but are made outside of Microsoft, which means we have another update schedule? No, because people value other browsers and most importantly Chrome and Firefox updates are so frequent we feel safe. If we assume AV vendors are as responsible as Chrome and Firefox developers, constantly pushing software updates so security bugs are fixed in no time, then why should we reject something that can be helpful?
How about Windows Defender? It's built-in, but doesn't have 100% successful rate in independent testing, and even so those are just samples that aren't like WannaCry, popping up out of nowhere.
So being able to defend the basic attacks is good enough. What really sucks is people are paying a lot of money for basic protection (and even more for the "Internet suite" and bundled with VPN etc). This is a true ripped off, but whether one is computer savvy or not, we can't take out a screw if all we have is bare hands and nothing else (nothing around you but on a lonely island without trees or plants or rocks but water and dirt). You can try by breaking the wall or the plank, but it would be a painful task. So take your risk. I won't stop you.
I hope you don't get downvoted through the floor for saying this, because that's the kind of reaction I've gotten the past n > 8 years for suggesting people don't run an antivirus on Windows.
I use Microsoft's own "Windows Defender" combined with Malware Bytes to catch any PUPs.
While I'm a very careful user, this combination, to the best of my knowledge, has kept me safe. (MalwareBytes caught a piece of commercial software that I paid $59 for -- a Blu-Ray player -- that tried to install a browser add-on that would have presented alternate advertising.)
Already years (~7+) ago AVG introduced an out of process scanning implementation that opens the file in question with system rights however transfers the handle to a lower privileged process (restricted with ACLs) that actually performs the actual scan
That's interesting. Unfortunately, AVG has been acquired by Avast last year [1]. I already looked into the new version of AVG a few months ago, and found that they have replaced AVG's engine with Avast's engine. Since the scanner always runs as NTAuthority\SYSTEM in the current Avast version, I would assume that the same is true for the most recent AVG version. I'm not completely sure, though, so don't quote me on that.
Well since I am no longer involved with them for a long time, I can't really say how this all went and what is currently the state.
However this piece is realtively simple to implement on windows so I can only hope they would implement the same thing for avast eventually at least. This is IMHO the only sane way to do scanning without exposing the system to a huge risk
Having an antivirus installed has so far consistently proven to make a system vastly less secure, degrade performance and reliably break a number of applications you might actually want to use. All of them have just fallen apart at the slightest scrutiny and they are routinely programmed by the last kind of people you want to design and implement them.
The whole concept is just useless. Scanning all system IO for 20 year old BIOS viruses is a pure waste of energy.
It seems like your prediction is not becoming reality.
I have the following issue: I would like to be able to download a file from the internet (jpeg, pdf, mp3, mp4, etc) without the risk of getting malware on a Windows machine. Or Mac. Or Linux.
Can't be done.
Everything is relying on crappy C code dragging around pointers and sizes, making index calculations, calling malloc and free.
That's right.
The list of anti-virus products that license the Bitdefender engine is extremely long.
Actually, I wanted to include the most prominent Bitdefender customers in the article to give an impression.
I ended up not doing so, because some license partner use the Bitdefender engine with disabled archive extraction. In this case, they would not be vulnerable to this bug, and I didn't want to mislead someone into thinking they are.
The definitions are licensed with the engine and can usually not be modified.
In a nutshell, most anti-virus vendors that are licensing the Bitdefender engine extend it with their own engine to improve their detection rate. For example, they support more exotic file formats and binary packers, or fancy heuristics, etc. Essentially this means they have the full attack surface from Bitdefender plus their own attack surface...
Might we agree to recommend to Microsoft users that they should use Microsoft AV. About 6 months ago we had a similar discussion [0] which arrived at that conclusion.
Bitdefender's core has dynamically loaded modules that are distributed with the regular definition update, which runs fully automatically. So there is nothing to do.
That fix could be a memory-safe language, or it could be sandboxing. But the assumption should be that for any antivirus product which does its file-parsing in C or C++, and which doesn't sandbox is scanning engine, there's going to be at least one critical vulnerability in the scanner. Bitdefender is still unsandboxed, so fixing this particular vulnerability is only of limited use; there are almost certainly other, similar vulnerabilities in it, so users running it are vulnerable to anyone with the resources to find one.
AV companies have mostly gotten away with this sort of thing in the past, because individual AV scanners tend to have low enough market share that they aren't as desirable targets as web browsers. But Windows Defender recently broke that trend by being present on every Windows system, and having a critical vulnerability, so now there are a lot more researchers looking at unsandboxed AV scanning engines and finding problems.