Consider this, Microsoft spends huge amounts of dollars and manpower creating protections for the Vista operating system, yet we still have old school vulnerabilities. Why? The answer is simple really, third-party created code is not stepping up and taking advantage of these powerful protection mechanisms.
I'm not the first to talk about this, certainly, but I feel it is very important to continue to bring to light until we see more widespread usage of these protections. In fact, I've seen a few really great discussions on the subject of these protections and where they succeed and fail just recently.
There's a number of protections that Vista has built-in, but for the purpose of this article, we're going to focus on DEP and ASLR.
- Data Execution Prevention (DEP) attempts to prevent execution of code from a non-executable memory region. There's two ways it's achieved, hardware-based and software-based, which are described below:
- Hardware-based DEP enables the No eXecutable (NX) bit on capable CPUs. Vista handles hardware DEP by marking certain areas of memory as being intended only to hold data which is interpreted by NX capable CPUs as being non-executable.
- Software-based DEP is also called Safe Structured Exception Handling (SafeSEH) by Microsoft and attempts to prevent the corruption of addresses of exception handling code, which resides in the applications stack frame and could therefore be vulnerable to hijacking.
- Address Space Layout Randomization (ASLR) is the process of randomizing the location of useful to attacker data areas, such as the base of executables and position of libraries, the heap, and the stack. This effectively means that if you can find a workable exploit, you may not be able to write exploit code as the key addresses used would change.
Unfortunately, the usage of DEP has caused some compatibility issues for applications that have self-modifying code, or perform just-in-time compilation, such as in the Java world; therefore, the usage of DEP is an opt-in protection. This means, we may not even have DEP protection in certain instances. Case in point, have a look at John Heasman's blog where he describes an attack against a Java applet through the use of an attacker crafted TrueType font that could execute native code when run from the applet.
On top of this, DEP does not provide any ASLR by itself, and ASLR is also an opt-in protection. Because of this, even if DEP is enabled, a vulnerable piece of code could still be exploitable as it may be possible to perform a return-to-libc type of attack. Return-to-libc attacks make use of existing functions to inject malicious code into a program by first preparing the stack to provide proper arguments to the function, and then overwriting the return address on the stack with the location of this instruction.
Additionally, DEP may be disabled altogether if ASLR is not in use, as is demonstrated by skape and Skywing (aka geniuses) in the "Bypassing Windows Hardware-Enforced DEP" paper on the Uninformed site.
What's really important to gather from all of this, is that while Windows has made major improvements to it's security, the components that we add to our OS are leaving those great security enhancements out, and that's a big problem. As Maynor mentions on his blog:
"Turning on the ASLR flag in all products will undoubtedly cause (or expose) a few bugs, but most software will run just fine. There is no reason for software companies to continue to ignore this issue. Among the companies/products currently ignoring these features are: Mozilla’s Firefox, Google’s toolbar, Apple’s iTunes, Adobe’s PDF reader, Roxio’s media creation tools, and Divx’s player. Actually, we haven’t found any company that turns on ASLR consistently."
Hopefully this will change sooner rather than later.