Tuesday, 10 August 2010

Built-in Windows Security features ignored by most AV vendors and common desktop applications but is this important?

A widely discussed topic in a many security blogs of late has been that of DEP and ASLR being neglected in many common desktop applications and more notably, desktop Antivirus software. Most of the posts, even if not directly accredited, were spawned by an interesting research paper authored by Secunia.

Background

DEP (Data Execution Prevention) is a Windows security feature that was introduced in Windows XP SP2 and has persisted in both Vista and Windows 7 (despite changes in how it is invoked by the OS). DEP is designed to prevent execution of services and applications from non-executable regions of memory, blocking exploits that store code via buffer overflow. This feature has to be enabled explicitly within the application in order to provide protection. DEP will not guard against more complex coding techniques such as ‘return-into-libc’ attacks that change the return address of a stack to a different location in memory containing an alternative instruction. In order to overcome this ASLR (Address space layout randomization) was introduced with the release of Windows Vista. ASLR randomises the location of key data areas in memory (such as libraries, heap and stack) in order to make it difficult for attackers to guess their location. These two features in combination can mitigate attacks targeting memory space if they are enabled within the respective applications. Additionally, there are several things worth noting with ASLR. Firstly, ASLR is not proprietary to Microsoft or a new concept and its security is greatly improved by increasing entropy by means of a larger address space.

Issues

It appears that many applications, including Antivirus software, do not take full advantage of what is a proven and easy to implement technology (although they are by no means impossible to crack) present in most Windows implementations. Some interesting responses from AV vendors, posted by Brian Krebs on his security blog, give some insight into the state of AV programming.

“Mikko Hypponen from F-Secure said that “adding support for DEP and ASLR in our products is on our roadmap, but has not been implemented yet. This is because we’ve focused our development efforts lately to focus on performance. Once we have this feature ready, it will be available to all of our customers through our update channel.””
“Pedro Bustamante, a senior research adviser at Panda Security, said Panda decided not to use either ASLR or DEP in favour of their own technology “to provide protection not only for the single AV processes but also for other types of operations. For example our products include a Shield component which already takes care of the protection as offered by ASLR and DEP, in addition to other types of self-protections such as preventing a process from injecting a thread into a separate process, preventing certain applications from executing dangerous operations on the system (such as Adobe Acrobat dropping an executable in the system and running it), protection of the AV files in the installation directories, etc.””

Given the conflicting stances on these two technologies from antivirus vendors, it’s difficult to decide which approach is better or if either is (?). However, I do feel that deciding not to use built-in features of an operating system, to be adding complexity in an area where performance is quite obviously an issue. That said, it may be quicker to take a different approach to doing the same thing in a different way, but why then is one technology better than another? With this confusion in mind, it does bring one back the quantitative metric of detection rates and if we care about the ‘how’ if the results are good? It would be interesting to look at detection rates vs. implementation of DEP and ASLR, but that’s slightly beyond the scope of this blog! However, I digress, the main issue is that DEP and ASLR are built in protections which are not being utilised by many popular applications and some will even admit to being remiss (even if it’s accompanied by marketing spin) in their exclusion.
Although the primary focus of this post, it’s not only Antivirus software that suffers from a lack of these functionalities. The most alarming, in my opinion, being Java (Sun java JRE)! To quote Secunia’s paper “Java resources are loaded and processed in the java.exe process and not in the context of the browser opening a web page that embeds a Java applet. DEP was found to be disabled in the java.exe executable included in the latest version of the software (6 Update 20). Furthermore, default libraries are loaded at fixed addresses.”

No comments:

Post a Comment