Why it's important to turn on DEP and ASLR Windows security features
In the quest for application security, many developers are disabling or incorrectly implementing two important Windows security features. In this expert response, Michael Cobb explains why ASLR and DEP should always be turned on.
I recently read that a recent Secuniaresearch effort found that many popular applications don't take advantage of two key security features in newer versions of Windows: address space layout randomization (ASLR) and data execution prevention (DEP). Do you have any opinion of why so few applications take advantage of it, and advice on how I can ensure our internal application developers can learn how to do so?
Before I answer your questions, let me just quickly explain for other readers what address space layout randomization (ASLR) and data execution prevention (DEP) are. The role of ASLR is to move the entry points of system code around in memory so they are in unpredictable locations. This makes it harder for malicious code to locate a system function in order to call it. For example, wsock32.dll might be in physical memory location 0x73200000 when you boot your machine today, but in 0x779b0000 when you boot it tomorrow. DEP is a set of software security checks designed to block malicious code by taking advantage of exception-handling mechanisms in Windows and executing code from data pages.
However, these security features only work if they are incorporated into an application by developers and Secunia's report (.pdf) reveals that many popular software applications don't yet support them, or developers improperly implement them. At the time of the report, Java, Apple QuickTime, Foxit Reader, Google Picasa, OpenOffice.org, RealPlayer and VLC media player all failed to integrate either DEP or ASLR. I imagine this is why many malicious hackers attack applications rather than Windows itself, as most Microsoft-built applications take full advantage of DEP and ASLR. Thankfully, since the report was published, several vendors have added support for these security options in recent patches, or are in the process of doing so.
I imagine the main reasons many organizations don't turn on DEP or ASLR Windows security features are time and money. However, having enterprise developers learn how to incorporate these security controls into internal applications is certainly recommended. If the enterprise's developers use Microsoft's Visual Studio, then implementing these two security features is fairly trivial and the process well documented. There are also several Microsoft resources online that provide step-by-step instructions on how to incorporate them into programs. The Visual C++ Team Blog covers setting the linker options /DYNAMICBASE and /NXCOMPAT: /DYNAMICBASE modifies the header of an executable to indicate whether the application should be randomly rebased at load time by the OS. ASLR and /NXCOMPAT are used to specify an executable as compatible with DEP. You can set these two options explicitly in Visual Studio and in Visual Studio 2010; the default setting is already set to "on."
Windows Vista SP1, Windows XP SP3 and Windows Server 2008 add a new API, SetProcessDEPPolicy, which allows a developer to set DEP on the process at runtime rather than using linker options. Microsoft's Michael Howard explains this in more detail on his blog while the MSDN Library covers some of the programming considerations and application compatibility issues you will need to take into account when using these controls.
ASLR and DEP are two important security features that enterprises should look to incorporate into their applications. Microsoft provides lots of information about how to do this, so even though it may be something new for developers to learn, it's not difficult, and applications will be a lot more secure as a result.
