Schuh points out in the Twitter thread that Chrome supports OS-level API's.
> its very rare to see an AV compromised
https://twitter.com/taviso/status/732365178872856577 https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...
> its very rare to see an AV compromised
https://twitter.com/taviso/status/732365178872856577 https://bugs.chromium.org/p/project-zero/issues/list?can=1&q...
If you read the notes you'll see scary terms like "buffer overflow" but "probably wont work on windows because windows uses /GS." I think Tavis does good work but the interpretation of his work is often hysterical. Finding an issue with AV doesn't invalidate the concept of AV. AV is just software. Bugs get found and patched like any other software. I think accepting that isn't asking too much here. Defect-free software is so far humanly impossible for non-trivial applications, let alone for complex security applications. Heck, how many security defects has the linux kernel and openssl had in the past couple years alone? Dozens, or more, and all have been weaponized and trivially exploited. Yet we still use that stuff.
Grandma's PC, the PC of a random staff person at work, etc without AV is taken down near instantly. With it, she can avoid many of these security issues. The idea that some defects means AV is without value is a fun and popular opinion with techies, but in the real wold, it does far, far more good than harm.
That's because the Linux kernel, Chrome, Firefox, etc. are installed on hundred of millions or billions of devices. Any given piece of anti-virus is orders of magnitude less popular. Further, the route to exploitation is often more circuitous with AV
Overall, that adds up to significantly less exploitation seen in the wild.
That's not true of the one issue which mentions Windows using /GS. For that issue (814), the bug actually says "Exploitation is likely still possible on Windows, but may be more difficult as they do use /GS on that platform."
Of the other eight bugs linked, four in the link were confirmed to allow code exec as NT AUTHORITY\SYSTEM on Windows. One more is "trivially exploitable" and allows reliable control of the instruction pointer but didn't specify as what user the code is running.
If it's unrealistic to ask that of AV software, then I'm not sure how this works out to be an argument for AV.