Less secure?
So, does this mean that adding, that version of, ESET antivirus actually makes your Mac less secure?
Bored hacker looking for fun? We couldn't possibly suggest you attack the latest vulnerability in ESET's antivirus software, because it's too basic to offer any challenge at all. As outlined in this advisory today, all you need to get root-level remote code execution on a Mac is to intercept the ESET antivirus package's …
Antivirus is a program running with system privileges that intercepts each and every filesystem call and has complete and arbitrary control over what it does with the data from that. It sees every byte that flows to and from storage, and is capable of trawling storage any time it likes with privileges beyond that available to any user (i.e. it can read locked and system files, etc.).
It auto-updates from a third-party on the Internet to gain new functionality, including downloading new executables and rulesets. It prevents you uninstalling it easily. It monitors every user, can access all of RAM, and has carte blanche over your system processes. If you have an AV suite with firewall built in, it's also capable of doing the same for network traffic while having the capability to exclude or hide any traffic it likes and even potentially acting as a man-in-the-middle for SSL with access to your trusted root certificate store so you can't even tell. It's also particularly hit-and-miss on real-world infections, and is more easily disabled by malicious software than by its own intended users. It's primary function in professional environments is mainly as a canary, where it talks home from every client to an installation on the local network with the same privileges and itself decides whether to alert the user if one of the client AV's drops off.
AV is, pretty much, the very definition of a bad idea. And yet it's still suggested that AV is REQUIRED for things like PCI DSS.
If you value your system security, an AV package is about the worst possible thing you can install.
Yes, but this is a route for the attacker to subvert the update mechanism of a security product to inject that code into the system - and run it with root privileges. The first step in subverting a system is the step of "how do you get the code onto the system" and the second step is "how do you run it". In a "secure" system, both of these steps are difficult.
This exploit isn't trivial to use - but it makes things a lot easier. Essentially, you need to setup a fake update server, then somehow get the victims computer to connect to it instead of the real one. Compromising their SoHopeless router and fiddling with the DNS can do that bit.
Were the update system secure, then an attempt to do this would trigger errors as you can't get a matching certificate for your fake server - or you shouldn't be able to ... <cough> Comodo <cough>.
This exploit isn't trivial to use
Well - I can think of a fairly trivial method involving a hotspot set to mimic popular hotspot names and a DNS server set to return a value of the config site that points to $BAD_SERVER..
Of course, in true semi-PHB techie mode, the actual exploit is a handwavy SEP.
Minion! Code me an exploit stat! What do you mean you don't know how? Just what do we pay you for? A Windows Dev? That contradicts your first argument!