Imagine this: a security control built right into Windows Server (enabled by default) that helps stop malware in its tracks as soon as the OS starts booting. Well, if you’re running Windows Server 2008 or R2, you’ve already got such protection. In fact, your enterprise clients running Windows Vista and Windows 7 have it as well. It’s called address space layout randomization (ASLR).
ASLR helps prevent buffer overflow attacks by randomizing the location where system executables are loaded into memory. If a DLL has its dynamic-relocation flag set then its location in memory is automatically randomized. Malware looking for certain files in specific memory locations is thus tripped up and cannot run its exploit. In fact, ASLR could cause the malware to draw attention to itself by crashing the very system file(s) it’s attacking.
Another neat thing about ASLR is that it plays nicely with Dynamic Memory, the new Windows Server 2008 R2 SP1 feature that dynamically allocates system memory to Hyper-V virtual machines as needed. Furthermore, ASLR has a negligible performance impact on client performance.
Of course, ASLR really isn’t anything new. Third-party endpoint protection vendors have offered ASLR for years. Ditto with Linux. But while Microsoft was a bit late to the game on this one, the only thing that matters now is that the company is building preventative controls against malware directly into the Windows OS -- arguably where it should’ve been all along.
So, why worry about a security control like ASLR on Windows Server-based systems? I still see a lot of servers that aren’t running anti-malware software in the name of performance or because they “don’t use this server for anything but file sharing and Active Directory management anyway.” The problem is that these servers are wide open for attack. The bad guys and their code don’t discriminate, making the servers fair game for numerous malware and vulnerability exploits.
Not everything is rosy with ASLR though, so you can’t forget the law of unintended consequences and let your guard down. Here are some things you can’t afford to overlook:
- ASLR works with any DLL file that that’s been written to support it, which means you’ve got to trust that your developers and vendors have enabled it for their code.
- It could lead to a false sense of security on Windows-based systems and thus a lack of maintenance and oversight for traditional malware protection, patch management and poorly-written code.
- There is the potential that ASLR could create certain system instabilities and performance issues by fragmenting memory over time.
- It’s not necessarily a prevention technology as much as it is an evasion technology. Presumably, malware could eventually detect/crack the location of the system files it’s trying to hook in to as outlined in this informative paper on PaX security. All things considered, however, this delves into the area of diminishing security returns and residual risk that everyone has to deal with in some fashion, so I’m not convinced you should let these issues keep you up at night.
One more thing to note is that to gain the full benefits of ASLR, it needs to be used in conjunction with Data Execution Prevention (DEP), a built-in memory protection feature designed to help protect applications from exploits. Fortunately DEP is also enabled by default in Windows Server 2003 SP1 and up.
All in all, ASLR is a step in the right direction in the fight against malware in the enterprise, but only time will tell just how effective it truly is.
You can follow SearchWindowsServer.com on Twitter @WindowsTT.
ABOUT THE AUTHOR
Kevin Beaver is an information security consultant, keynote speaker, and expert witness with Atlanta-based Principle Logic, LLC where he specializes in performing independent security assessments. Kevin has authored/co-authored eight books on information security. He's also the creator of the Security On Wheels information security audio books and blog providing security learning for IT professionals on the go. Kevin can be reached at his website http://www.principlelogic.com/.
This was first published in March 2011