Windows Vista introduces a range of new technologies that make the most secure desktop version of Windows to date. The following article provides an objective analysis of one of these improvements. Our goal is to help people better understand the true security climate that awaits them with Windows Vista, in this case with DEP (Data Execution Prevention).
Security technologies in Windows Vista
With the introduction of Windows Vista, Microsoft has leveraged a number of security technologies in order to mitigate several classes of attack that have historically plagued the Windows operating system. These technologies are numerous, and are best described visually in the following figure:
Figure 1: Security technologies present in Windows Vista Operating System. Note that DEP technology is part of Generic Exploit Mitigation block.
Something of history
DEP was introduced in Windows XP Service Pack 2 and Windows Server 2003 Service Pack 1. This feature, present as NX (EVP) in AMD's processors and as XD (EDB) in Intel's processors, can flag certain parts of memory as containing data instead of executable code, which prevents overflow errors from resulting in arbitrary code execution.
Introduction to DEP
Data Execution Prevention (DEP) helps prevent an application or service from executing code in a non-executable memory region. DEP is a security feature available in modern Microsoft Windows operating systems.
In others words, DEP blocks a malicious program in which a virus or other type of attack has injected a process with additional code and then tries to run the injected code. On a system with DEP enabled, execution of the injected code causes an exception. DEP blocks programs that take advantage of exception-handling mechanisms in Windows.
How does DEP work?
DEP runs in two modes. DEP is a set of hardware and software methods that perform additional checks on memory. These checks help prevent malicious code from running in the memory of your computer.
DEP helps prevent certain exploits or attacks from programs that store code via for example a buffer overflow.
Hardware-enforced DEP: provides instructions to the CPU to mark certain memory pages as non-executable. Hardware-enforced DEP technically sets a bit in the page table entry that tells the system to prevent code from being executed from a virtual memory page that should contain only data.
Software-enforced DEP: protects only user-mode processes. It must be supported by the operating system. Software-enforced DEP does not protect from execution of code in data pages but instead from another type of attack which is called Security Exception Handling (SEH) overwrite.
Programming Considerations
An application can use the VirtualAlloc function to allocate executable memory with the appropriate memory protection options. It is suggested that an application set, at a minimum, the PAGE_EXECUTE memory protection option. After the executable code is generated, it is recommended that the application set memory protections to disallow write access to the allocated memory. Applications can disallow write access to allocated memory by using the VirtualProtect function. Disallowing write access ensures maximum protection for executable regions of process address space. You should attempt to create applications that use the smallest executable address space possible, which minimizes the amount of memory that is exposed to memory exploitation.
You should also attempt to control the layout of your application's virtual memory and create executable regions. These executable regions should be located in a lower memory space than non-executable regions. By locating executable regions below non-executable regions, you can help prevent a buffer overflow from overflowing into the executable area of memory.
Application Compatibility
Some application functionalities are incompatible with DEP. Applications that perform dynamic code generation (such as Just-In-Time code generation) and do not explicitly mark generated code with execute permission may have compatibility issues on computers that are using DEP. Applications written to the Active Template Library (ATL) version 7.1 and earlier can attempt to execute code on pages marked as non-executable, which triggers an NX fault and terminates the application; for more information, see SetProcessDEPPolicy. Most applications that perform actions incompatible with DEP must be updated to function properly.
What is the advantage of using DEP?
The main advantage of DEP is to help prevent your computer from executing code in memory data pages. In most cases, code is usually not executed from the default heap and stack.
Hardware-enforced DEP detects code that is running from these locations and raises an exception when an execution occurs.
Software-enforced DEP supplements the hardware Data Execution Prevention by preventing malicious code from taking advantage of exception-handling mechanisms in Windows.
How can I know if DEP is available on my computer?
-
To open System Properties, click Start, click Control Panel, and then double-click System.
-
Click the Advanced System Settings link or tab and, under Performance, click Settings.
-
Click the Data Execution Prevention tab.
By default, in Windows XP and Windows Vista, DEP is only turned on for essential Windows operating system programs and services, as shown in Figure 2. To help protect more programs with DEP, select the option: Turn on DEP for all programs and services except those I select.
Figure 2: Default DEP configuration in Windows XP and Windows Vista.
In Windows XP and Windows Server 2003 the Data Execution Prevention DEP setting can be also implemented in your BOOT.INI file through the NOEXECUTE switch. The Boot.ini file settings are as follows: /noexecute= policy_level, where policy_level is defined as AlwaysOn, AlwaysOff, OptIn, or OptOut.
-
OptIn: This setting is the default configuration for Windows XP. On systems with processors that can implement hardware-enforced DEP, DEP is enabled by default for limited system binaries and programs that "opt in". With this option, only Windows system binaries are covered by DEP by default and cannot be disabled without changing the policy to "AlwaysOff". This is also the default in Windows Vista; however in 64-bit Vista 64-bit applications are always opted in.
-
OptOut: This setting is the default configuration for Windows 2003 SP1. DEP is enabled by default for all processes. A list of specific programs that should not have DEP applied can be entered using the System dialog box in Control Panel. Network administrators can use the Application Compatibility Toolkit to "opt out" one or more programs from DEP protection. System compatibility fixes, or shims, for DEP do take effect. Also note that Windows silently disables DEP for certain executables, such as those packaged with ASPack.
-
AlwaysOn: This setting provides full DEP coverage for the whole system. All processes always run with DEP applied. The exceptions list to exempt specific programs from DEP protection is not available. System compatibility fixes for DEP do not take effect. Programs that have been opted out by using the Application Compatibility Toolkit run with DEP applied.
-
AlwaysOff: This setting does not provide any DEP coverage for any part of the system, regardless of hardware DEP support.
Figure 3: Example of Boot.ini file settings in Windows Server 2003. Note that the default setting is OptOut.
In Windows Vista you use bcdedit tool to set the DEP mode for specific OS loaders. To set this use the /set nx switch. For example to set the currently booted OS to DEP a police_level you would use the command: bcdedit /set nx police_level, where policy_level is defined as AlwaysOn, AlwaysOff, OptIn, or OptOut.
Note that you should run bcdedit from a command window with elevated privileges. To do so:
-
On the Start menu, click All Programs, Accessories, and then Command Prompt.
-
Right-click Command Prompt and click Run as administrator on the context menu.
-
A User Account Control dialog box appears. Click Continue to run the command window with administrative privileges.
Figure 4: Example of use of bcdedit tool. Note that the default setting is OptIn option.
Figure 5: Example of use of bcdedit tool. Note that in this case we set AlwaysOn option.
Figure 6: Example of use of bcdedit tool. Note that now the current setting is AlwaysOn option.
Security implications of default configuration of DEP.
In default installations of Windows Vista, we observed that DEP technology is applied by default only to the core operating system. This limitation leaves third-party applications on Windows Vista with less protection than the core and the services. This fact increases the chance of successful exploitation of vulnerabilities present in these applications. For example even common applications such as Internet Explorer do not receive the benefits of DEP.
If DEP is enabled for all applications, users gain additional resistance against zero-day exploits. But not all applications are DEP-compliant and some will generate DEP exceptions. Therefore, DEP is not enforced for all applications by default in 32-bit versions of Windows and is only turned on for critical system components. However, Windows Vista introduces additional NX policy controls that allow software developers to enable NX hardware protection for their code, independent of system-wide compatibility enforcement settings. Developers can mark their applications as NX-compliant when built, which allows protection to be enforced when that application is installed and runs. This enables a higher percentage of NX-protected code in the software ecosystem on 32-bit platforms, where the default system compatibility policy for NX is configured to protect only operating system components. For x86-64 platforms, backward compatibility is not an issue and therefore DEP is enforced by default for all programs. Also, only processor-enforced DEP is used in x86-64 versions of Windows Vista for greater security.
Other implementations
Many operating systems implement or have an available NX policy, and some implement or have available NX emulation:
-
Initial PG_NX support first appeared in FreeBSD -CURRENT on June 8, 2004 and is a part of FreeBSD since 5.3 release.
-
Mac OS X for Intel supports the NX bit and PAE on the i386 arch, supported by Apple from 10.4.4, the first Intel release.
-
NetBSD 2.0 and later (December 9, 2004), architectures which support it have non-executable stack and heap.
-
A technology in the OpenBSD operating system, known as W^X, currently takes advantage of the NX bit in the AMD64 port. OpenBSD also supports W^X on some CPUs without an NX bit.
-
Solaris has supported globally disabling stack execution on SPARC processors since Solaris 2.6 (1997); in Solaris 9 (2002), support for disabling stack execution on a per-executable basis was added.
-
Red Hat's Linux developer Ingo Molnar released a patch named Exec Shield to approximate and use NX functionality on 32-bit x86 CPUs.
Glossary
NX: The NX bit, which stands for No eXecute is a technology used in CPUs to segregate areas of memory for use by either storage of processor instructions (or code) or for storage of data.
EVP: NX implementation. AMD uses the name Enhanced Virus Protection.
XD: The feature NX bit is named XD bit (eXecute Disable) by Intel.
EDB: NX implementation. Intel uses de name Execute Disable Bit.