The Living Dead Anti-Virus

Posted by    on   Feb 2, 2017

A former director of testing at AV-TEST and a one-time VB conference speaker, security consultant Hendrik Pilz is passionate about the quality of security products. In a guest blog for Virus Bulletin, he explains why he doesn't think anti-virus products should be disabled.

hendrik pilzJust recently, security expert Robert O'Callahan (a former developer at Mozilla) published an article in which he argued that users should disable all anti-virus software running on their machines other than Microsoft's own Windows Defender. He accuses AV vendors of writing insecure software, and of impeding the implementation of security features in software such as web browsers.

But while these arguments are true for some AV vendors, the suggestion that users should uninstall every AV product except for Microsoft Windows Defender is terribly wrong. I've been working in the security industry for more than a decade. I was the director of the AV-TEST testing lab, which publishes regular reports on the performance of AV software (similar to Virus Bulletin's testing). I was involved in the development and automation of so-called 'real-world tests'. Such tests simulate real user behaviour in order to test the full spectrum of security features included in today's AV software. During an automated test, a malicious URL is accessed with a web browser. Then, either a download dialog appears or else the AV has blocked the access to the URL. When one wants to create a comparative test that includes all the major AV programs (we usually tested 20 to 30 programs at a time), one quickly discovers that there is no common way in which the AV software interacts with the browser. This was the cause of many headaches in developing the automated tests.

And this is what O'Callahan is really complaining about. Due to the many 'tricks' AV vendors use to check web traffic, browser developers are faced with countless errors and bugs that are hard to reproduce and fix. Yet, in all the years I’ve been working in this industry, I've never witnessed a discussion between browser developers and AV vendors in an attempt to fix these issues. Instead, we regularly read about AV breaking encryption with various methods in order to scan the web traffic in the browser. The major browser vendors, Mozilla, Google and Microsoft, could create a standard for interaction between AV and the browser – in the past few years, we’ve seen many new W3C recommendations for technologies that are to be implemented in browsers, but there has never been a recommendation regarding the interaction between anti-virus (or third-party applications in general) and the browser. Instead, browsers have implemented their own security features, such as Google's Safe Browsing.

Users can rely on Safe Browsing and other security features integrated in browsers to stay safe. But soon many users will demand more options, such as the creation of group-based security policies or the central monitoring of web activities. For example, parents may want to restrict the Internet usage of their children, and corporate administrators may want to allow or disallow access to certain websites. While corporate administrators could move such policies to a network device such as the Internet gateway (having IP-based policies vs. user/group-based policies as a trade-off), parents can’t do that so easily. Now, the parents can request this feature from Google or Mozilla (or Apple, Opera etc.), or they can install a third-party product to provide it. I’d really like to see browser developers adding such a feature to the core of their browsers.

With Windows 10, Microsoft has introduced the Anti-Malware Scan Interface (AMSI). AMSI can be used by application developers to request a scan of any object (e.g. a file or a piece of JavaScript code embedded in a web page) with an AMSI-capable security application. This is a good start, but it remains something of a chicken-and-egg situation: as long as application developers don’t utilize AMSI to request scans for untrusted input, AV vendors don’t need to implement AMSI support. When Mozilla and Google start to include AMSI support in their browsers, AV vendors will easily be able to adopt AMSI in their products, with the result being that most developer headaches will be eliminated. This goes for the AV developers as well, as they will no longer have to resort to using their own root certificates to break encryption in the browser, and other workarounds. So the AV software will become less complex and thus more secure.

There is a need for security applications which extend basic security features. AV developers and browser developers need to discuss their respective requirements in order to find a proper solution to the problems of interaction between AV and browsers. AMSI could be the beginning of this solution.

twitter.png
fb.png
linkedin.png
googleplus.png
reddit.png

 

Latest posts:

Test your technical and mental limits in the VB2017 foosball tournament

As has become tradition, VB2017 will once again see a security industry table football tournament. Register your team now for some great fun and adrenaline-filled matches in between sessions in Madrid!

The case against running Windows XP is more subtle than we think it is

Greater Manchester Police is one of many organizations still running Windows XP on some of its systems. This is bad practice, but the case against running XP is far more subtle than we often pretend it is.

Hot FinSpy research completes VB2017 programme

Researchers from ESET have found a new way in which the FinSpy/FinFisher 'government spyware' can infect users, details of which they will present at VB2017 in Madrid.

Transparency is essential when monitoring your users' activities

Activity monitoring by security products in general, and HTTPS traffic inspection in particular, are sensitive issues in the security community. There is a time and a place for them, VB's Martijn Grooten argues, but only when they are done right.

VB2017 preview: Android reverse engineering tools: not the usual suspects

We preview the VB2017 paper by Fortinet researcher Axelle Apvrille, in which she looks at some less obvious tools for reverse engineering Android malware.