Problem solve Get help with specific problems with your technologies, process and projects.

Windows ASLR: Investing in your secure software development lifecycle

Implementing Windows ASLR can be a worthwhile investment in your enterprise’s secure software development lifecycle.

In a recent Microsoft report, Microsoft said only about one of every three commonly used Windows applications uses ASLR. Why don’t a larger number of application developers use it? Is it harder to use than Microsoft says it is? For enterprises that develop their own Windows apps, is it practical for us to encourage our developers to use ASLR?

Microsoft’s Security Development Lifecycle Progress Report echoes the findings of an earlier report by Secunia ApS, which also found a low implementation rate of Windows ASLR (Address Space Layout Randomization) amongst popular software applications. ASLR was introduced in Windows Vista and combats attacks by loading program modules into a different, random area of memory each time, but it only works for applications that explicitly enable it when they are compiled.

There are a few reasons behind its slow adoption. I think some developers are reluctant to change the way they build programs and may not even be aware of the new security technologies that Microsoft has been introducing.

Also, having to re-engineer existing software to incorporate new mitigation technologies is costly. Changing settings can break an application or change its behavior, so plenty of testing is required. But putting time and money ahead of security is a false economy. Practicing secure coding does require upfront investment, but based on a 2010 report from Aberdeen Group, the average cost required to mitigate and fix a security vulnerability is $300,000. That pays for a lot of investment in a secure development software lifecycle.

A different issue is ASLR support wasn’t built into Windows XP, which is still the dominant Windows platform. Data Execution Prevention (DEP), on the other hand, was introduced in Windows XP Service Pack 2 and was enabled in 71% of the applications Microsoft studied. While DEP is easier to implement, implementing ASLR is not difficult; Visual Studio 2010 enables ASLR by default. The technology is well documented and there are several Microsoft resources online that provide step-by-step instructions on how to incorporate it into an application.

Microsoft’s SDL initiative for creating a systematic approach to secure software development has made Windows more secure. This is one reason why we’re seeing more attacks against other applications rather than Windows itself. ASLR is an important security feature enterprises should incorporate into their applications. 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. Software vendors who don’t support ASLR and other security initiatives in their applications are likely to be heavily targeted if they are adopted by their competitors.

If you are concerned applications running on your Windows XP machines are vulnerable to ASLR-based attacks, consider using Microsoft’s Enhanced Mitigation Experience Toolkit 2.0 (EMET), which can retroactively apply various security mitigation technologies, including Mandatory Address Space Layout Randomization (Mandatory ASLR) to selected applications. Mandatory ASLR can force the operating system to load a dynamic link library written before ASLR was available to a random location regardless of the flags it was compiled with. Another advantage of using EMET is that you don’t need to recompile your own in-house software to set the various flags to enable DEP and ASLR.

This was last published in October 2011

Dig Deeper on Secure software development

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.