Self-Protection for Antivirus Software

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.