Exploit Mitigations in Windows
Comparing exploit patterns across different systems shows a clear trend: Newer software releases, like Windowsâ€¯7 and the 2007 Microsoft Office system, are consistently less prone to active exploitation than older releases.
These are some of the significant exploit mitigation technologies that have been added to Windows over the past few years:
Data Execution Prevention (DEP): Buffer overflow attacks, in which an attacker forces a program or component to store malicious code in an area of memory not intended for it, are some of the most common exploits seen today. DEP is a Windows feature that enables the system to mark one or more pages of memory as non-executable. Marking memory regions as non-executable means that code cannot be run from that region of memory, which makes it harder for exploits involving buffer overruns to succeed.
DEP was introduced in Windowsâ€¯XP SP2 and has been included in all subsequent releases of Windows desktop and server operating systems. For application compatibility reasons, DEP is â€œopt-inâ€ in Windowsâ€¯XP, Windows Vista, and Windowsâ€¯7. DEP protects the operating system and core system files by default, but application developers or IT administrators must specifically configureâ€¯other programs to take advantage of DEP. (DEP is â€œopt-outâ€ in Windows Server operating systems, meaning that DEP is enabled for all programs unless specifically disabled for a program.)
Address Space Layout Randomization (ASLR): In older versions of Windows, core processes tended to be loaded into predictable memory locations upon system startup. Some exploits work by targeting memory locations known to be associated with particular processes. ASLR randomizes the memory locations used by system files and other programs, making it much harder for an attacker to correctly guess the location of a given process. The combination of ASLR and DEP creates a fairly formidable barrier for attackers to overcome in order to achieve reliable code execution when exploiting vulnerabilities.
ASLR was introduced in Windows Vista and has been included in all subsequent releases of Windows. As with DEP, ASLR is only enabled by default for core operating system binaries and applications that are explicitly configured to use it via a new linker switch.
/SafeSEH and /GS (compiler flags): Introduced in the Visual C++Â® .NET 2002
(also known as VC7) compiler, /SafeSEH and /GS are compile-time flags that developers can use to make their applications harder to exploit in the face of
stack-based buffer overruns. For a great overview of /GS and its effectiveness, see â€œGS cookie protection â€“ effectiveness and limitations. For more information on how this security feature is being enhanced in Visual Studio 2010, see the Visual C++ Team Blog.
Structured Exception Handler Overwrite Protection (SEHOP): Another common technique used by exploit writers is to overwrite an exception handler to gain code execution. SEHOP stops this entire class of exploits from working by verifying that a threadâ€™s exception handler list is intact before allowing any of the registered exception handlers to be called.
SEHOP was introduced in Windows Server 2008 RTM and Windows Vista SP1, and has been included in all subsequent Windows releases. For application compatibility reasons, SEHOP is disabled by default on Windows Vista and Windowsâ€¯7 and is only enabled by default on server versions of Windows. See Â â€œPreventing the Exploitation of Structured Exception Handler (SEH) Overwrites with SEHOPâ€ for more information.
Windows Heap Manager Security Enhancements: Two new heap manager checks were introduced in Windowsâ€¯XP SP2 and Windows Server 2003 SP1 that make exploiting heap overruns less reliable. Additional checks have been added to the core in Windows Vista and newer operating systems. See the Â â€œPreventing the Exploitation of User Mode Heap Corruption Vulnerabilitiesâ€ or more information about these new security enhancements.
Safe Unlinking in the Kernel Pool: Windowsâ€¯7 and Windows Server 2008 R2 include code that makes it much harder for attackers to exploit kernel pool overruns. See t â€œSafe Unlinking in the Kernel Poolâ€ for more information.