Disable Your Antivirus Software (Except Microsoft's)
robert.ocallahan.org
robert.ocallahan.org
Avoid Non-Microsoft Antivirus Software (ocallahan.org)
859 points by bzbarsky 118 days agoI read an article saying what you comment, and I decided to try without. Feels a bit odd and I'm slightly paranoid, but this argument pushed me to follow you: it's not a good idea to give critical access to a 3rd party software that might be adding more bugs to you "backdoor policy".
> More likely, they hurt security significantly; for example, see bugs in AV products listed in Google's Project Zero.
This is not an indicator of insecure software. Not dealing with these disclosures are. Just a few weeks ago a major vulnerability was found in Defender.
Let's use my favorite AV as an example, NOD32:
- It performs HTTPS MITM which should obviously be disabled immediately. Score 1 Microsoft.
- Javascript runtime running as SYSTEM, which can't be disabled. Score 1 NOD32.
- There are two issues in Project Zero, making it exactly as secure as Defender according to that ignorant "vulnerabilities in Project Zero" metric.
- 4 days and 1 day for NOD32. 8 days and 3 days for Microsoft. Score 1 NOD32.
> At best, there is negligible evidence that major non-MS AV products give a net improvement in security.
- The NOD32 intrusion detection supposedly thwarted EternalBlue (Wanacry).[1] Defender did nothing. Score 1 NOD32.
Because Defender didn't need to do anything on a currently patched Windows machine. Call it a draw, although this entire comparison is deeply silly.
That doesn't follow at all. My plaintext traffic going through Chrome is likely far safer than my traffic going through the software of some middling Slovakian AV vendor.
In May 2017 we learned about this, from Project Zero no less:
https://bugs.chromium.org/p/project-zero/issues/detail?id=12...
> (Microsoft, on the other hand, is generally competent.)
I'd argue that the Project Zero issue, while fixed, shows that the design of Windows Defender is anything but competent. They have a full power JavaScript runtime engine running as SYSTEM. No sandboxing, no lowprivs, and the whole point is to run untrusted code.
I would have understood that if it was a small company and a lone developer made a mistake. However, this is Microsoft, a huge company. Lone developers don't get to decide things like this at companies the size of Microsoft. Most likely, meetings were held, architects were involved, code was reviewed. How did such a horrible decision make it through that process ?
Now, that can be directly useful for e.g. mail or file servers on those platforms, but a lot of customers simply had to buy AV everywhere for compliance reasons. They'd be running the AV scan in cron checking for Windows viruses on AIX.
Discussions with those people were funny. They knew what they were buying was worthless and made that clear, we knew our product was worthless to them and made that clear. But their boss's boss had obligated them to buy AV, so sure, if they wanted it anyway we were going to make it and take their money.
I suspect Android AV exists for much the same reason.
- Android "administrators" (read: end users) are generally less likely to be cognizant of potential viral vectors than a traditional Linux/AIX/Solaris/etc. administrator.
- Android is capable of providing root access to applications should a user configure the device to do so, thus giving malicious software an avenue to break out of what's otherwise a pretty decent per-app sandbox. This is a concern due to the point above.
- Variation between Android installations (as far as malware authors might be concerned) is far less than the variation in Linux/Unix installations (especially server installations), so there's a higher probability of one exploit or vector being applicable elsewhere.
- Pirated software is more common on an Android device than on a Unix server.
A good AV solution on Android is therefore valuable, especially considering that Android malware does exist in significant quantities. It's less valuable if you've never rooted your phone and have never installed apps outside of the Play Store (or something else that uses its repository, like the Yalp Store), but still does offer some value beyond compliance reasons.
If I need to open a document, I will upload it to some online office suite and read it there.
If I receive some potentially malicious email I will read the message source and verify it's legit.
I also don't use Windows anymore, but when I did, this strategy worked well for me.
But, it's become so drastically commoditized that there's no reason for the average user to have anything but the built-in MSE (on windows, at least).
It doesn't stop new attacks, but it does help raise the bar against malware.
It also provides a giant new attack surface.
A yummy target for virus and ransomware authors is a widely used piece of software: OS, browser, crypto library, Word processor, spreadsheet, PDF reader,...
Part of the problem is that in each of these categories, a single vendor often holds over 50% market share. As soon as a bug in one of those allow a RCE, that means millions of users at risk.
It's also true even if you don't run the software directly but use a service: memes that infect social media (see: Facebook and fake news) are basically viruses too.
Species avoid extinction from viruses thanks to diversity. Software users that want to stay safe should consider using the less popular alternatives.
This point is badly under-discussed whenever this AV debate comes up.
Yeah, the variety of vendors, products, and methods in the third-party AV arena make production less predictable for software developers. That's the point. It makes it exactly as unpredictable for attackers.
Should AV vendors work harder to make their software easier to develop around? Arguably, yes. Security through obscurity is no security at all. But that should be the target of the argument, not the homogenization of security systems. I don't care how big or small the Defender attack surface is if every single desktop computer in the world has the exact same attack surface.