Get on-the-go access to the latest insights featured on our Trustworthy Computing blogs.
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
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
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. 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.
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.
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
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
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 email@example.com.
Matt Miller, MSEC Security Science