Skip navigation

Self-Protection for Antivirus Software

An Internet security suite provides full system protection, employing all available protection technologies. But what about the self-protection of the system protectors? Do they use protection technologies such as DEP and ASLR for their own use? AV-TEST examined 32 applications to find out.

Consumer Antivirus Software: Some manufacturers could still vastly expand the use of DEP & ASLR in the future (last amended: 10/14).

Endpoint Security Solutions: In the business versions, there is increasing reliance on the additional protection of DEP & ASLR (last amended: 10/14).

DEP & ASLR in Consumer Versions: The use in 64-bit files is mostly higher than in 32-bit files; but it is not the rule (AV-TEST, last amended: 10/14).

DEP & ASLR in Business Versions: Nearly all the manufacturers rely increasingly on the use of DEP & ASLR as additional protection in the business versions (AV-TEST, last amended: 10/14).

In science fiction films, when a space ships is attacked, its deflector shields are not merely hit by accident, rather there is always an initial targeted attack on the deflector shield generator. In the real world of antivirus software, the deflector shield generator would be the kernel of the security suite – the antivirus application itself. If the deflector shield fails, then the ship – or in our case, the Windows system – is left unprotected and easy to commandeer.

Naturally, manufacturers of security packages have known about this for a long time. That is why they have devised and deployed a number of measures for self-protection. What many users do not know: Several years ago, the IT sector developed open-access protection mechanisms that programmers can use in their source code – ASLR and DEP.

The experts from AV-TEST looked under the hood of 24 security suites and 8 corporate security solutions in October 2014 to see whether they are already using ASLR and DEP. For this check, 32- and 64-bit files were evaluated separately.

The somewhat cryptic terms ASLR and DEP stand for:

ASLR or Address Space Layout Randomization stands for a shuffling of memory sectors, making it more difficult to exploit security gaps in computer systems. Using ASLR, stack addresses are randomly allocated to applications. This is intended to prevent, or at least impede, attacks via a buffer overflow.

DEP or Data Execution Prevention is also referred to as NX-Bit (No eXecute). The protection is already based on the hardware. Chip producers AMD and Intel have already been implementing this technology for ten years under the proprietary names of EVP and XD-Bit in all their processors. It is intended to prevent programs from executing random data as programs and thus launching malicious code in this manner.

Oldies but Goodies

The ASLR and DEP technologies are easily more than 10 years old, yet they are as current as ever. Their main purpose is the following:

A comprehensive program code is seldom error-free. According to Wikipedia (German version), top programs only have 1 error in 2000 lines of code. However: Photoshop CS6, for example, consists of some 9 million lines of code, Windows XP of roughly 40 million. A good overview on the topic of how many lines of code are contained in programs can be found in an infographic by London designer David McCandless.

Unavoidable errors may later turn out to be vulnerabilities that the malicious code of a hacker can take advantage of. A security suite knows these vulnerabilities and attempts to plug up all the holes. But after all, a security suite is a program as well, consisting of several files and inordinate lines of code. The suite itself could have an Achilles' heel that an attacker could exploit. That would naturally be disastrous.

If support of ASLR and DEP technologies is included during programming, this reduces the risk of an existing vulnerability actually becoming exploitable. If an application does not employ ASLR and DEP, this does not necessarily mean that it is unsafe. After all, if the programming is 100% error-free, the level of security cannot be increased either. Thus ASLR are DEP are an additional precaution that no one should do without. Because implementing them is a snap: it involves existing functions in the compiler that simply need to be activated. The volume of code and program run time are not influenced by it.

32 products evaluated

In its evaluation, AV-TEST wanted to find out how heavily the manufacturers employ the additional protection in their products. To do so, individual products were installed and all new files available were logged. Afterwards, the user-mode PE (portable executable) files for 32 and 64 bits were used for the evaluation. All the other files, including the so-called native PE files, were irrelevant for the test. The PE files include, for example:

.exe or any "executable" program or module
.dll or "dynamic link library", a program library
.sys or "system" software
.drv or "driver", a driver file for a device

Between 5 and 45 percent of the installed files of a security solution are PE files, which were examined in terms of whether they are additionally protected in the code with DEP and ASLR.

In the tables, a percentage value was recorded documenting how many of the PE files – separated according to 32 and 64 bits – have the additional protection. The result is a bit surprising, as some manufacturers partially or full deploy ASLR and DEP, while other manufacturers do without it almost completely.

Consumer Products: not everyone uses additional protection

The laboratory performed the tests segregated according to products for consumers and for business. For the Internet security suites catering to consumers, a total of 24 products were examined and also listed separately according to 32 and 64 bits. The only products that use ASLR and DEP 100 percent are from ESET (consumer) and Symantec (business). Avira, G Data, McAfee and AVG (both products) deploy the additional protection 100 percent only in the 64-bit files of their product. For the 32-bit version, the value varies between 90 and nearly 100 percent.

In total, half of all security packages rely over 90 percent on the use of ASLR and DEP. Afterwards the use declines in steps of roughly 10 percent from product to product, down to the smallest value of some 5 percent. In one instance, involving Kingsoft, usage was even 0 percent for 64-bit files.

With many 64-bit files, regardless of ASLR or DEP, the use of the security technology is higher than for 32-bit files. But there was no apparent rule.

Business Products: high percentage of use

For corporate solutions, manufacturers rely much more heavily on the additional self-protection of ASLR and DEP. Only Symantec consistently uses the protection 100 percent. Sophos only for its 64-bit files. Sophos points out, however, that among its 32-bit files a large number of the unprotected files are DLLs, which only contain data and thus do not pose any risk. If we add together the 32- and 64-bit values for each product, the use in 6 out of 8 products is between 81.5 up to more than 97 percent. Trend Micro is the only one that doesn't rely on this technology and thus implements ASLR and DEP in just under 19 percent of its PE files.

Overall it is clear: the self-protection is used more often in 64-bit files than in 32-bit files. However, this is only a trend and not a rule.

Summary: Enhanced protection never hurts

The use of the open-access technologies ASLR and DEP is highly recommended to the manufacturers. After all, it is additional protection that cannot hurt. Admittedly, even ASLR can be outflanked by spraying techniques, as reported in a German article at heise online (Die Rückkehr der Pufferüberläufe), translating as "The return of buffer overflows". However, outwitting ASLR requires much more effort for the author of malicious code. Effort that is normally avoided.

Nor is DEP (or NX-Bit) the ultimate protection of files, but authors of exploits are required to scale additional hurdles for this as well, which in turn means more effort.

It's often the sum of all things that counts. The effort required to defeat two, three or more firewalls costs the attacker time, resources and additional steps, which protection software can possibly identify more easily as an attack.

Here's what the manufacturers say

AV-TEST sent the findings of the evaluation to all the manufacturers and simultaneously asked why they may not be implementing DEP and ASLR. In summary, here are the replies:

  • There are some of the third-party libraries that do not use DEP and ASLR. But in the future, there are plans to only use libraries that implement these technologies.
  • Individual files work with a proprietary security technology that would not be compatible with DEP and ASLR.
  • Particular files were prepared for special protection using a non-Microsoft-compliant compiler and are therefore incompatible with DEP and ASLR.
  • Certain files are no longer actively used in the application and are thus negligible.
  • Proprietary protection technologies are used, such as CFI (Control Flow Integrity) and sandboxing technology.

ASLR and DEP Expertise

Director Malware
Research: Ulf Lösche

The more code a written program has, the higher the probability that an error may lead to a potential vulnerability. Using the technologies ASLR and DEP, these vulnerabilities cannot be directly eliminated, but they can be more effectively hidden and protected from access. In principle, a programmer should only do without ASLR and DEP if the program is 100 percent error-free.

One of the greatest longtime advocates of these technologies is Microsoft. ASLR has been used without exception since Windows Vista. DEP has been supported since version XP SP 2. Windows has been unjustly discredited as a system with many vulnerabilities. The fact is, however, that almost always it is an installed third-party software that tears gaps in a Windows system. Popular examples of this specimen are the Adobe Reader, Flash or Java. Microsoft constantly reports on the latest trends in this area in its Security Intelligence Report. These reports are freely accessible.

Currently there is also a good study from Joxean Koret, COSEINC. In his presentation (PDF), he vividly illustrates that the existing vulnerabilities in antivirus software can harbor great risks: Breaking Antivirus Software.

Already in 2005, AV-TEST reported on vulnerabilities in security software and explained the ramifications they can have. More information on this topic is available as a pdf: Insecurity in Security Software.

Share news: