Anti-virus, a cure worse than the disease?

This blog post will explore situations in which anti­-virus software caused more harm than good. As the anti-virus landscape changes, software vendors are eager to provide new functionality to stay ahead of the competition. Vendors have started to implement features that are designed to detect and remove threats before they are fully present on a user's system. Some are developing custom, security-­focused web browsers and web browser plugins. Others are devising methods to intercept user traffic to detect threats in transit.

Avast SafeZone

The first topic of this post will be custom browsers developed by anti­virus vendors. One such vendors is Avast. Avast bundles its SafeZone browser with installations of Avast Premier 2016, Avast Internet Security 2016, and Avast Pro 2016. SafeZone was developed as a fork of Google's open source Chromium browser. On December 18, 2015, a critical issue was posted on the google­-security­-research Google Code project.

User taviso discovered a Remote Procedure Call (RPC) endpoint created on his machine by an Avast service called AvastSvc.exe. After investigating the protocol, taviso determined that it was possible to send arbitrary RPCs to the Avast service by having a user visit a malicious website.

Most of the RPC commands discovered were not particularly dangerous. However, one command taviso found will launch the SafeZone browser, taking a URL as a parameter. When this command executes, a new instance of SafeZone will start, opening the specified URL as a tab. This flaw can be used to cause a user to inadvertently visit another malicious website.

Recall that SafeZone is a fork of Google Chromium. By default, Chromium only allows WebSafe URLs, such as those beginning with http://, https://, javascript:, data:, etc. However, this is not the case with SafeZone. These restrictions were removed during SafeZone's development—allowing use of various other types of URLs, including file:// and chrome:// URLs.

Using this information, and a particular chrome-devtools function, the reporting user was able to execute JavaScript and further send and read authenticated HTTP requests using Chrome's cookie store. Since devtools are permitted to examine external resources, file:// URLs can be requested, leading to arbitrary file reads. The reporting user claims that with enough time the attack could likely be elevated to code injection.

This issue was resolved on February 3, 2016, with the release of Avast 2016 Version 2016.11.1.2253.

Comodo Chromodo

Comodo also provides its own browser in the form of the Chromodo browser. Unlike SafeZone, this browser does not require a paid subscription to a Comodo product in order to download and install. On January 21, 2016, taviso again posted a critical issue was on the google-security-research Google Code Project Chromodo was disabling the Same-Origin policy, breaking a critical aspect of web security.

Comodo pushed out a fix by February 5, 2016.

AVG Web TuneUP

Like other vendors, AVG also decided to expand into the browser space. However, rather than designing a custom browser, AVG decided to develop a plugin called AVG Web TuneUP instead. The Chrome variant of this plugin would be automatically installed along with AVG's anti-virus software.

On December 15, 2015, user taviso reported multiple critical vulnerabilities on the google-security-research Google Code project. Multiple instances of information leakage and cross-site scripting were discovered. Some example code provided in the bug report demonstrated the ability for a malicious website to read email messages from

This issue was considered resolved by the reporting user on December 28, 2015.

SSL Interception

Anti-virus vendors have also been experimenting with Transport Layer Security (TLS) interception features designed to increase user security. In order to do this, vendors need to first install their own root certificates in the users’ browsers. When a web browser requests a website over HTTPS, the browser confirms that the certificate submitted by the server is trusted. Normally, an error will be raised if the certificate is invalid. When software actively intercepts a TLS connection, the software will be using a certificate that does not match that of the remote server, thus resulting in the browser reporting an invalid certificate. In order to circumvent this protection, anti-virus vendors add their own certificates to the browsers’ lists of trusted certificates. This configuration is known as a man-in-the-middle.

Typically, the browser is responsible for properly negotiating the TLS connection. However, once the anti-virus software intercepts the connection, it must properly handle the connection itself. In a blog post from April 2015, Hanno Böck investigates TLS intercepting software from three anti-virus vendors: Avast, Kaspersky, and ESET. In all three cases, the intercepting software TLS implementations were found to be flawed.

HTTP Public Key Pinning (HPKP) is a security mechanism designed to protect against invalid keys issued by compromised certificate authorities. After a successful TLS connection, the server can pin public keys of its certificate in the user's browser. The browsers keep a list of these pins and their associated hostnames.

In future communications with this server, the browser will search its database of stored pins for one that matches the certificate for the current TLS session. In short, if no stored pin matches the certificate provided by the server, the connection is terminated. Avast, Kaspersky, and ESET all failed to properly implement HPKP, weakening the security posture for all users of their products.

In addition to a flawed HPKP implementation, Kaspersky also left users vulnerable to the TLS FREAK attack due to the use of an outdated version of OpenSSL long after popular browsers had updated. Kaspersky users were also vulnerable to the CRIME attack by allowing use of a flawed TLS compression feature. This issue has been mitigated in Firefox and Chrome since September 2012.

Third party anti-virus software was once a basic requirement for machines running Microsoft Windows operating systems. Today, the use of anti-virus software is shifting from required to potentially dangerous. The critical flaws being discovered across the industry are very concerning for the end user. Users are expecting to increase their security posture by running well-known anti-virus software from renowned vendors; however, as demonstrated by the cases outlined in this blog post, this is not always the case.

In 2009, Microsoft released its own first-party anti-virus software in the form of Microsoft Security Essentials (MSE) for Windows XP and newer. Today, support for XP has been discontinued, but Windows Vista and 7 continue to be supported. Since Windows 8, MSE has been baked into the operating system as Windows Defender.

The case for a third-party anti-virus solution is weaker than ever. Microsoft is providing its own free solution that has not fallen victim to any critical security bugs as of the writing of this post. Additionally, third-party vendors continue to make serious mistakes in the development of their security-focused software. And of course, smart Internet browsing can be the strongest anti-virus measure available.

This is not to say that third-party solutions are pointless. Windows Defender has been out-performed by numerous alternatives in various tests:

This leaves users in a sort of catch-22 situation.

Ultimately, it falls to the consumer to decide if the possibility of higher detection rates justifies installing potentially dangerous software.

Additional Information

Readers interested in further details about this topic can reach us at: