Protecting Your Software

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.

Top of page Top of Page

Managing Risk


United States Change All Microsoft Sites



Was the information in this article helpful?