Hi, Michael here,

Over the last few weeks, Matt Miller, Matt Thomlinson, John Lambert and I worked on a paper that describes the various buffer overrun defenses we offer in Windows Vista and later and Windows Server 2008 and later.

I’d like to introduce a guest SDL blogger, Matt Miller, a member of our Security Research and Defense team, who has written a great article that describes the rationale behind the paper.


Over to Matt…


On our Security Research and Defense blog we have previously described the security benefits of mitigation technologies like Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR)[1,2].  These technologies and others like them (SEHOP, GS, etc) are designed to make it more difficult for attackers to reliably exploit software vulnerabilities.  The growing prevalence of these technologies has contributed to increased interest from the security research community on the subject of developing new bypass techniques[3]. We value the research community’s findings in this area and are continuing to work on improving the effectiveness of our mitigation technologies.  In the meantime, there are important steps that Independent Software Vendors (ISVs) must take to ensure that these mitigations are as effective as possible.


In practice, the effectiveness of mitigations like DEP and ASLR is heavily dependent on how completely each mitigation technology has been enabled by an application.  Failing to completely enable a mitigation technology leaves low-hanging fruit that an attacker can use to their advantage when developing an exploit.  In June, 2010, Secunia released a study which measured the usage of DEP and ASLR in products developed by various ISVs[4].  This report showed that the majority of the surveyed applications do not completely enable these mitigations and therefore expose footholds that attackers can use to more easily exploit vulnerabilities. 

This point was most recently illustrated in the form of an exploit that was written for Adobe Reader (CVE-2010-2883) where the attackers took advantage of a DLL that had not opted-in to ASLR.  Adobe has done a commendable job of enabling mitigations like ASLR for the majority of their components, but the fact that at least one DLL existed that had not opted-in to ASLR was enough to give attackers a leg up.  This same rule applies to other applications as well; for example, BHOs and ActiveX controls that have not opted-in to ASLR can allow attackers to bypass ASLR in conjunction with any browser-based vulnerability.  These examples show the importance of fully enabling mitigations.


How to verify an application’s ASLR settings

There are two general approaches that can be used to verify the ASLR settings of an application.  The first approach involves verifying that the EXE and DLLs that are currently loaded by the application all have ASLR enabled.  Sysinternals Process Explorer provides easy access to this information by setting the lower pane to view DLLs for a process and adding the “ASLR enabled” column to the view.  The screenshot below provides an example of using Process Explorer to observe a non-ASLR DLL (jp2ssv.dll) that has been loaded into the context of Internet Explorer (denoted by an empty value for the ASLR column).

While Process Explorer is a very useful tool for verifying the ASLR settings of DLLs that have been loaded in a running process, it is not able to provide you with information about DLLs that are not actively loaded by the application.  This information can be obtained through the use of Microsoft’s BinScope Binary Analyzer.  BinScope inspects the on-disk settings embedded in EXEs and DLLs and verifies that the required flags (DYNAMICBASE) have been set in order for ASLR to occur.  The screenshot below provides a simple example of a report produced by BinScope where one DLL does not opt-in to ASLR (nodynamicbase.dll) and one DLL does opt-in (dynamicbase.dll):

Guidance for ISVs                                                                                                                         

In an effort to help ISVs fully take advantage of the security features provided by Windows we have published updated guidance which shows how mitigation technologies like DEP, ASLR, and GS can be enabled.  This guidance can be found in the report linked below:




We encourage ISVs to follow this guidance and, more generally, the guidance provided through the Security Development Lifecycle (SDL).  We also encourage ISVs who have questions regarding the adoption of mitigation technologies to contact us at switech@microsoft.com.


Matt Miller, MSEC Security Science