Are any AV vendors marketing themselves as more secure than the competition, with technically founded evidence? Such as memory-safe PLs, VM or OS sandboxes, running 3rd party native code in an emulator, bug bounties, etc.
Though probably their customers are mainly corporate "intranet" environments where users open random content with Acrobat, Office etc and the high bit is to just halve (1) the daily mass malware infections - which are not av focused yet.
(1) or whatever the average AV detection rate is these days.
A/Vs are largely attack vectors, a huge number of malware already tries to detect if an A/V is present and then uses it to get SYSTEM level privilege fairly easily.
The number of actually good A/Vs is low and in my opinion, simply use Microsoft Defender on Windows. For 0-days it's detection rate is, to my knowledge, not significantly worse than any other A/V and unlike other products they properly integrate into the system and don't disable almost all security measures of the kernel like ASLR and friends so they can inject some garbage DLL into any process.
The best protection for the intranet customer is training and regular software updates. For the average user it's to tighten up security, lock them out and then run regular updates.
My main reason for using Microsoft Defender is the business model. It's in best interest of A/V companies for people to have viruses, it's in best interest of Microsoft for people not to have viruses on Windows.
The difference is that Microsoft has more incentive to optimise their AV against both false positives, and false negatives. And it can afford to stay invisible if there is no threat. A commercial AV has to make its presence known, and most I've seen do this constantly: If you never get a virus and the program remains silent all the time, people will wonder if they really need a commercial AV. If you never experience trouble and Microsoft Defender stays silent, you have a happy user: Windows works without issues.
So is Defender. The scanner runs as NT AUTHORITY/SYSTEM without any sandbox. One flaw in the scanner is a widespread and nearly wormable exploit. You can infect an entire company by just spamming them if you found an exploit in the file type parsers it uses.
Here's a bug found by Project Zero. The researcher had trouble getting the test case to Microsoft because Defender was running on their middleware boxes and would automatically scan it and die from the exploit testcase.
I'm skeptical of any AV provider. Most try to lock shit down insanely, and thash my disk more insanely. I rebelled against having to use the top-of-the-line AV tool my company tried to enforce because it crippled development speed, scanning and locking files breaking builds.
It feels like grade-school collective punishment because the office dope is watching anime porn on sketchy sites on the office subnet.
Wow, this is a neat exploit. It breaks ASLR with a static payload, only employing some decompression tricks to combine randomized addresses with fixed ROP targets. I like the technique and I think it could be more generally applied to file exploits.
I've been using computers my entire life but this read like it was in Greek to me. Very impressive that people out there actually understand all that stuff. I'm not sure where to begin learning about that.
The way the author uses the RAR decoder engine itself to mutate parts of an existing (randomized) function pointer, defeating ASLR, is pretty damn neat.
That is false. It's likely the end-user can update it, but the LGPL does not prevent it from being impossible.
The LGPL makes it perfectly legal for the closed-source antivirus component to not load any 7zip .so binary that is not signed by the antivirus vendor, of a known hash, or so on... and the code loading said shared-object need not be available or modifiable, just the code for the vulnerable .so they do ship.
The LGPL clearly states that a Combined Work which includes the the Library must "1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version." as well as insisting that the terms of the license under which you distribute the Application "effectively do not restrict modification of the portions of the Library contained in the Combined Work and reverse engineering for debugging such modifications" <- taken together, maybe (maybe!) you could make an argument that your shared library loader was legit while the code using that shared library loader was evil (though that clearly violates the intention of this license in a way that is so blatant I would be shocked if a judge or a jury didn't shake their heads at your claim), but then the rest of the anti-virus software wouldn't be able to be distributed under a typical commercial license as modifications and reverse engineering of that code would have to be allowed.
I always wondered whether code signed deployment is not compliant with LGPL and where the threshold lies.
Specifically, if forcing to sign a package with a different key (making it a different package) for private purposes is enough, or if the redistribution rights of the whole is required.
Finally, if you cannot replace the software because of code signing and no public debug mode, that seems incompatible too...
LGPL or not, if I remember correctly, F-Secure does not enforce a valid signature of the 7-Zip library, so you can replace it yourself. Don't quote me on this though.
However, F-Secure applies several patches to harden 7-Zip and to fix bugs that are not yet fixed in the public 7-Zip version. So it is not clear whether it is always such a good idea to do this.
An article about something assuming domain knowledge? Say it ain't so!
F-Secure: an antivirus
RAR: an ancient archival format
ASLR: address space layout randomization, a system which loads code at unpredictable locations to make exploits harder to write (as you don't know where to jump)
ROP chain: Return Oriented Programming. A way to circumvent non-executable memory protection and ASLR by manipulating the call stack to jump into to existing executable code segments (called gadgets) and chain them together as each returns to the next.
RarVM: an ill concieved mechanism allowing code to be embedded in RAR archives.
Though probably their customers are mainly corporate "intranet" environments where users open random content with Acrobat, Office etc and the high bit is to just halve (1) the daily mass malware infections - which are not av focused yet.
(1) or whatever the average AV detection rate is these days.