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.
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):
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:
http://msdn.microsoft.com/en-us/library/bb430720.aspx
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
Adam Shostack here.
I've been working on an SDL requirement since a few weeks after I joined the company. For this blog post, what it is matters less than how we've gotten here, and for where we are, I must thank and blame Steve Lipner. It has been, at times, a frustrating journey. Wearing my security hat, the destination was (and is) obviously worth achieving. But that's not enough to bring something into the SDL. To be part of the SDL, it needs to be achievable for the thousands of engineers at Microsoft who will be required to comply.
Yesterday, Steve Lipner was honored by the ISSA and inducted into their hall of fame. We've been talking on the SDL team about what we want to say about Steve. A great deal of his career is publicly known, and what he's done for us here at Microsoft is a little harder to talk about in ways that convey the tremendous value that Steve brings to us. What he's done here is guided a substantial chunk of the team that was once the "Secure Windows Initiative" into the Microsoft Security Development Lifecycle. In doing so, he's helped to take Microsoft from being the butt of security jokes to an exemplar for many organizations setting out on a path to building more secure code.
The first version of a requirement that I tried to shepherd was insufficient. After a conversation with Eric and with Steve, I voted against it myself, despite the many hours of late night phone calls that went into it. I let someone else write the second draft, and it turned out the tooling wasn't good enough. This is an important point as to why the SDL works for us here, and it's a point that Steve gently forces on all of us: if we can automate it, we have to automate it. The product groups are often overwhelmed with requests. Threat modeling suffers from this in spades: we ask a huge amount of every engineer in threat modeling their code. We created the "STRIDE per element" approach to make it possible for typical non-security engineers to do it. The tools have to scale to the sorts of products we build, and the diversity of platforms and languages our product teams use.
What Steve taught me in saying no to the second draft was the importance of sufficient tools. In saying no, he forced me to pick that requirement up, and get it to be good enough for our product teams. It's now prescriptive, with clear entry and exit points. The tool story makes sense. And teams are executing on it after our beta period. We're finding and fixing real issues. And the things we're asking are achievable.
Earlier in his career, Steve worked on an A-1 system for DEC. What that meant was big formal mathematical proofs that first the system had been mathematically proven to have certain properties that a few key buyers cared about, and second that it was so late to market that those key buyers bought other stuff in the meantime. (Ironically, those properties were ones that researchers like Anderson, Bell, La Padula and Biba had talked about while working for...well, you can guess, or you could look it up over at Matt Bishop's collection of classic papers in information security. It's not for nothing that Steve was brought into a hall of fame.)
But I think that Steve's most impressive achievement has not been the pragmatism that he's brought to the SDL. It's how he's taught all of us how important it is to temper our security goals with a pragmatism that enables us to achieve them. It's a lesson that can help not only the information security industry, but also all those companies who are selling non-security products: you can make them secure and trustworthy.
Thanks, Steve, and congratulations on your induction!
Dave again!
We’ve been asked if commercial enterprises can use the SDL documentation that we recently released under a Creative Commons license. It seems that there is some confusion within the IT community regarding our use of a CC license that stipulates non-commercial terms. The purpose of this post is to clarify our intent in releasing the SDL materials under a Creative Commons license and to define acceptable uses of these materials.
All organizations, including for-profit enterprises, may copy, distribute and transmit any SDL content we release under the Attribution, Non-Commercial, Share Alike (cc by-nc-sa) terms. This means that businesses are free to incorporate the SDL content we release under this Creative Commons license into their internal process documentation and development methodologies and to use the SDL content to advance the development of secure software, provided the terms of the license are followed. Microsoft released the SDL content under this Creative Commons license to enable individuals, organizations and businesses to incorporate security and privacy into software development practices. Microsoft, however, does not extend this license grant to organizations or individuals whose primary purpose is to generate revenue by reselling the SDL content.
Our intent here is to make it easier for all organizations to incorporate security and privacy into their development practices. By incorporating security and privacy into the development lifecycle of many businesses, we get more secure software, which reduces risk for the entire computing ecosystem.
If you have questions about commercial uses of the SDL content, please feel free to post your question on the Microsoft SDL forums – we’d be happy to help