> If you read the notes you'll see scary terms like "buffer overflow" but "probably wont work on windows because windows uses /GS."
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.
and they were patched before they could be properly exploited. Its odd to expect AV to be defect free but to excuse defects in other software. I think we're holding AV up to a quality level that's unrealistic here and also dismissing its everyday benefits for average users.
I think that "Don't run several pieces of years-old third-party software with multiple publicly-known code execution vulnerabilities as root/SYSTEM on possibly malicious input" is a bare minimum requirement to demand of a piece of software whose entire purpose is to analyze untrusted data to prevent malicious code from executing on our machines.
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.
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.