Export (0) Print
Expand All
Expand Minimize

Data Execution Prevention

Applies To: Windows Server 2003 with SP1

What does data execution prevention do?

Data execution prevention (DEP) is a set of hardware and software technologies that perform additional checks on memory to help protect against malicious code exploits. In Windows Server 2003 with Service Pack 1, DEP is enforced by both hardware and software.

Hardware-enforced DEP

Hardware-enforced DEP marks all memory locations in a process as non-executable unless the location explicitly contains executable code. There is a class of attacks that attempt to insert and execute code from non-executable memory locations. DEP helps prevent these attacks by intercepting them and raising an exception.

Hardware-enforced DEP relies on processor hardware to mark memory with an attribute that indicates that code should not be executed from that memory. DEP functions on a per-virtual-memory-page basis, usually changing a bit in the page table entry (PTE) to mark the memory page.

The actual hardware implementation of DEP and marking of the virtual memory page varies by processor architecture. However, processors that support hardware-enforced DEP are capable of raising an exception when code is executed from a page marked with the appropriate attribute set.

Both Advanced Micro Devices (AMD) and Intel Corporation have defined and shipped Windows-compatible architectures that are compatible with DEP.

32-bit versions of Windows Server 2003 with Service Pack 1 utilize the no-execute page-protection (NX) processor feature as defined by AMD or the Execute Disable bit (XD) feature as defined by Intel. In order to use these processor features, the processor must be running in Physical Address Extension (PAE) mode. The 64-bit versions of Windows use the NX or XD processor feature on 64-bit extensions processors and certain values of the access rights page table entry (PTE) field on IPF processors.

It is hoped that all future 32-bit and 64-bit processors will provide support for hardware-enforced DEP. Microsoft continues to work with processor vendors to encourage the adoption and development of DEP technologies.

Software-enforced DEP

An additional set of DEP security checks has been added to Windows Server 2003 with Service Pack 1. These checks, known as software-enforced DEP, are designed to mitigate exploits of exception handling mechanisms in Windows. Software-enforced DEP runs on any processor that is capable of running Windows Server 2003 with Service Pack 1. By default, software-enforced DEP protects only limited system binaries, regardless of the hardware-enforced DEP capabilities of the processor.

Who does this feature apply to?

Application and driver developers should be aware of DEP and the requirements of software running on a supporting platform. Applications that perform just-in-time (JIT) code generation or execute memory from the default process stack or heap should pay careful attention to DEP requirements.

Driver developers are encouraged to be aware of PAE mode on platforms supporting hardware-enforced DEP. PAE mode behavior on systems running Windows Server 2003, Standard Edition with Service Pack 1, is changed to improve driver compatibility.

What new functionality is added to this feature in Windows Server 2003 Service Pack 1?

Data execution prevention on 32-bit and 64-bit versions of Windows and applications

Detailed description

Hardware-enforced DEP

To provide consistency for application and driver developers, the memory protection model (including DEP) is designed to be the same for both 32-bit and 64-bit versions of Windows.

Application developers should be aware of DEP behavior in user mode. A user-mode DEP exception results in a STATUS_ACCESS_VIOLATION (0xc0000005) on Windows systems. The first parameter of ExceptionInformation that is located inside the EXCEPTION_RECORD structure contains the type of access violation that occurred. A value of 8 for ExceptionInformation[0] indicates the access violation was an execution violation.

In most processes, the STATUS_ACCESS_VIOLATION exception will be an unhandled exception and result in termination of the process.

DEP is also applied to drivers in kernel mode. DEP for memory regions in kernel mode cannot be selectively enabled or disabled. On 32-bit versions of Windows, DEP is applied to the stack by default. This differs from kernel-mode DEP on 64-bit versions of Windows, where the stack, paged pool, and session pool have DEP applied.

Device drivers are not permitted to execute code from the stack when DEP is enabled. A DEP access violation in kernel mode will result in an error 0xFC: ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY.

Software-enforced DEP

Software-enforced DEP performs additional checks on exception handling mechanisms in Windows. If the program’s image files are built with Safe Structured Exception Handling (SafeSEH), software-enforced DEP ensures that before an exception is dispatched, the exception handler is registered in the function table located within the image file.

If the program’s image files are not built with SafeSEH, software-enforced DEP ensures that before an exception is dispatched, the exception handler is located within a memory region marked as executable.

DEP application close behavior

The majority of applications will not encounter a problem with DEP. However, when an application does encounter a problem with DEP, a Data Execution Prevention message is presented to the user, alerting them to the problem.

The Data Execution Prevention message indicates that a DEP problem occurred with the application and provides the ability for the user to learn more about DEP and optionally disable DEP for the application that was closed.

ImportantImportant
If a DEP problem occurs with an application, Microsoft recommends contacting the application vendor for an update. The security implications of disabling DEP for an application should be thoroughly considered before disabling DEP for an application.

The ability to change DEP settings for a closed application using the Change Settings button on the Data Execution Prevention message window depends on the system-wide DEP configuration. Changes to DEP protection for an application can be made only if the system-wide DEP configuration is set to the OptOut mode.

The Data Execution Prevention message is presented immediately before a Windows Error Reporting window, which provides the opportunity to submit a report about the DEP problem to Microsoft.

On Windows Server 2003 with Service Pack 1, the Data Execution Prevention message will be presented the next time an Administrator logs onto the system interactively. The behavior is changed on Windows Server 2003 with Service Pack 1 from Windows XP with Service Pack 2 because Windows Error Reporting is configured in queued mode by default. Queued mode causes error reporting messages to be queued until the next time an administrator interactively logs onto the system.

To learn more about Windows Error Reporting, or to configure Windows Error Reporting such that DEP and Windows Error Reporting messages are displayed immediately following an application problem, see the "Using Windows Server 2003 in a Managed Environment: Windows Error Reporting" article on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=38443.

Windows Error Reporting generates an error signature when an application is closed due to DEP. The error signature can be viewed by following the "click here" link on the Windows Error Reporting dialog. The error signature for a DEP problem has the following attributes:

 

Parameter Example Value Description

EventType

BEX

Indicates a buffer overflow (/GS) or DEP exception (BEX64 indicates a buffer overflow (/GS) or DEP exception on 64-bit versions of Windows)

P1

DEPDemo.exe

Name of the application executable that encountered the problem

P2

5.1.2600.2180

Version of the application executable that encountered the problem

P3

416725f2

Faulting application stamp

P4

DEPDemo.exe

Faulting module name

P5

5.1.2600.2180

Faulting module version

P6

416725f2

Faulting module stamp

P7

00002060

Fault offset (Instruction address if a module is not loaded at the faulting address)

P8

C0000005

Indicates a STATUS_ACCESS_VIOLATION exception (If this parameter is c0000409, the problem is a /GS-related fault)

P9

00000008

Indicates an execution STATUS_ACCESS_VIOLATION (00000002 indicates an execution STATUS_ACCESS_VIOLATION on 64-bit versions of Windows for the Intel Itanium architecture)

Finally, the Data Execution Prevention message might not be shown for some applications when they encounter a problem with DEP, regardless of the Windows Error Reporting configuration. These applications handle the STATUS_ACCESS_VIOLATION exception raised by DEP, or they install an unhandled exception filter (UEF), which overrides the default Win32 UEF. The default Win32 UEF is responsible for triggering both the Data Execution Prevention and Windows Error Reporting messages. The Data Execution Prevention message may also not be shown if an application has called the SetErrorMode() function with the SEM_NOGPFAULTERRORBOX flag.

Why is this change important? What threats does it help mitigate?

The primary benefit of DEP is that it helps to prevent code execution from data pages such as the default heap, various stacks, and memory pools. In normal operations of the system, code is not typically executed from the default heap and stack. Hardware-enforced DEP detects code that is running from these locations and raises an exception when execution occurs. If the exception is unhandled, the process will be terminated. Execution of code from protected memory in kernel mode results in an error.

Although terminating a process or causing the system to fail with an error do not appear to be ideal experiences, this helps prevent malicious code from executing. Preventing malicious code from executing on the system may prevent damage to the system or propagation of malicious code whose harmful effects could easily exceed those of a terminated process or system error.

DEP can help prevent some exploits in which a virus or other attack has injected a process with executable code and then attempts to execute the injected code. On a system with DEP, execution of the injected code should result in an exception. Software-enforced DEP can help mitigate exploits of exception handling mechanisms within Windows.

A secondary benefit of DEP relates to good engineering and best practices for application and driver developers. DEP forces developers to avoid executing code out of data pages without explicitly marking the pages as executable.

What works differently?

Application Compatibility

Some application behaviors are expected to be incompatible with DEP. Applications that perform dynamic code generation (such as just-in-time code generation) and that do not explicitly mark generated code with Execute permission might have compatibility problems with DEP. Applications that are not built with SafeSEH must have their exception handlers located in executable memory regions.

Applications that attempt to violate DEP will receive an exception with status code STATUS_ACCESS_VIOLATION (0xC0000005). If an application requires executable memory, it must explicitly set this attribute on the appropriate memory by specifying PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE or PAGE_EXECUTE_WRITECOPY in the memory protection argument of the Virtual* memory allocation functions. Heap allocations using the malloc() and HeapAlloc() functions are non-executable.

Driver compatibility

Driver compatibility issues with DEP mostly center on PAE mode-induced compatibility issues.

noteNote
PAE is required only on systems running 32-bit versions of Windows with processors that support hardware-enforced DEP.

On its own, DEP might create compatibility problems with drivers that perform code generation or use other techniques to generate executable code in real time. Although many drivers with such behavior would have been fixed — as DEP is "always on" for drivers loaded on 64-bit versions of Windows — there is no guarantee that all drivers have been updated. However, there are few drivers that employ these techniques, and it is not expected that DEP alone will cause a large quantity of driver compatibility problems.

The primary driver compatibility concern is running Physical Address Extension (PAE) mode on 32-bit systems. PAE mode enables processors to address greater than 4 gigabytes (GB) of memory. The primary difference between PAE memory paging and non-PAE memory paging schemes is the extra level of paging that is required in PAE mode (three levels instead of two).

Some drivers might fail to load if PAE is enabled, because the device might be unable to perform 64-bit addressing or the drivers might assume that PAE mode requires more than 4 GB of random access memory (RAM). Such drivers expect that they will always receive 64-bit addresses when in PAE mode and that they or their device are incapable of interpreting the address.

Other drivers might load in PAE mode but cause system instability by directly modifying system page table entries (PTEs). These drivers expect 32-bit PTEs, but receive 64-bit PTEs in PAE mode instead.

The largest driver PAE compatibility issue involves direct memory access (DMA) transfers and map register allocation. Many devices that support DMA, usually 32-bit adapters, are not capable of performing 64-bit physical addressing. When run in 32-bit mode, the device can address all physical address space. In PAE mode, it is possible that data would be present at a physical address greater than 4 GB. To allow devices with these constraints to function in this scenario, Windows 2000 Server and later operating systems provide double-buffering for the DMA transaction by providing a 32-bit address that is indicated by a map register. The device can perform the DMA transaction to the 32-bit address and the kernel copies the memory to the 64-bit address that is provided to the driver.

When the system runs with PAE disabled, drivers for 32-bit devices never require their map registers to be backed by real memory. This means that double-buffering is not necessary, since all devices and drivers are contained within the 32-bit address space. Based on testing of drivers for 32-bit devices on 64-bit processor–based computers, it is expected that most client-tested, DMA-capable drivers expect unlimited map registers.

To constrain compatibility issues, Windows Server 2003, Standard Edition with Service Pack 1, includes hardware abstraction layer (HAL) changes that mimic the 32-bit HAL DMA behavior. The altered HAL grants unlimited map registers when the system is running in PAE mode. In addition, the kernel memory manager ignores any physical address above 4 GB. Any system RAM beyond the 4 GB barrier would be made unaddressable by Windows and be unusable in the system. By limiting the address space to 4 GB, devices with 32-bit DMA bus master capability will not see a transaction with an address above the 4 GB barrier. Because these changes remove the need to double-buffer the transactions, they avoid a class of bugs in some drivers related to proper implementation of double buffering support.

Note that the PAE behavior of Windows Server 2003, Enterprise Edition with Service Pack 1, and Windows Server 2003, Datacenter Edition with Service Pack 1, is unchanged from the versions without the service pack.

As a result of these changes to the HAL and memory manager, the impact to device driver compatibility is expected to be minimal on systems running Windows Server 2003 with Service Pack 1 with DEP enabled.

System compatibility

A final DEP compatibility concern derives from systems with PAE mode enabled, even though they may not be designed for more than 4 GB of physical RAM. During internal testing Microsoft has noticed that some systems with processors that support hardware-enforced DEP fail to start up or have other stability issues when the processor is running in PAE mode.

PAE mode is a requirement for leveraging the NX processor feature. Therefore, system designers and firmware engineers should be aware that even though the system’s chipset and firmware may not have been designed to support more than 4 GB of physical RAM, the system may be running in PAE mode.

Of particular concern is system firmware that interprets page table entries to determine instructions executed by the operating system. Page table entries are extended to 64 bits in length when the processor is running in PAE mode. System designers and firmware developers are encouraged to contact their processor and chipset vendors for more information about how to safely determine instructions executed by the operating system.

System designers working with AMD processors can obtain more information in the "BIOS and Kernel Developer’s Guide for AMD Athlon 64 and AMD Opteron Processors." To obtain this paper, go to the AMD Athlon 64 Web site at http://go.microsoft.com/fwlink/?LinkId=28165 and click "BIOS and Kernel Developer’s Guide for AMD Athlon 64 and AMD Opteron Processors."

Intel does not make detailed information about System Management Mode (SMM) available publicly. System designers working with Intel processors are encouraged to contact Intel directly for more information.

For more information regarding Windows support for PAE mode, see "Physical Address Extension - PAE Memory and Windows" on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=45912.

How do I resolve these issues?

Applications that require executable regions of memory must use the PAGE_EXECUTE, PAGE_EXECUTE_READ, PAGE_EXECUTE_READWRITE, or PAGE_EXECUTE_WRITECOPY attributes when allocating memory. Additionally, applications cannot execute from the default process heap or the stack. Most applications that perform actions incompatible with DEP will need to be updated to be compatible. Applications must also be built with SafeSEH or ensure their exception handlers are located in memory explicitly marked as executable.

An application can use the VirtualAlloc() application programming interface (API) function to allocate executable memory with the appropriate memory protection options. At a minimum, the PAGE_EXECUTE memory protection option should be used. After the executable code has been 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 using the VirtualProtect() API function. Disallowing write access ensures maximum protection for executable regions of process address space.

If a malicious process attempts to insert code into an executable region, the access would result in a STATUS_ACCESS_VIOLATION write exception. The application should attempt to make the executable regions of its address space as small as possible. This would result in a smaller attack surface through which executable memory could be injected into the process address space and be executed.

Additionally, sophisticated applications can control the layout of their virtual memory and create executable regions. These applications should attempt to locate executable regions in a lower memory space than non-executable regions. The purpose of locating executable regions below non-executable regions is to protect a buffer overflow from overflowing into executable memory.

A small number of executables and libraries may contain executable code in a data section of the image file. In some cases, applications may place small segments of code (commonly referred to as thunks) in the data sections. However, DEP will mark sections of the image file loaded in memory as non-executable unless the section has the executable attribute applied.

Therefore, executable code in data sections should be moved to a code section, or the data section containing the executable code should be explicitly marked as executable. The executable attribute, IMAGE_SCN_MEM_EXECUTE (0x20000000), should be added to the Characteristics field of the corresponding section header for sections that contain executable code.

The Microsoft linker that is distributed with Microsoft Visual Studio products can add the executable attribute to a section using the /SECTION linker option. The /SECTION linker option has the following format:

/SECTION: Name ,[E][R][W][S][D][K][L][P][X][,ALIGN=#]

The E value indicates the executable attribute (0x20000000). More information about /SECTION and other Microsoft linker options is available on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=28167.

Additionally, the Microsoft COFF Binary File Editor (Editbin.exe) utility can be used to change the section attributes of an existing image. The Editbin utility has a /SECTION option with the following format:

/SECTION: Name [= newname ][,[[!]{CDEIKOMPRSUW}][A{1248PTSX}]]

The C and E values indicate code and executable attributes respectively. For more information about the Editbin utility and the /SECTION option, see the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=28168.

Microsoft has provided service packs for Microsoft .NET Framework version 1.0 and version 1.1 to take advantage of DEP in Windows Server 2003 with Service Pack 1. Applications that use the Microsoft .NET Framework will continue to function normally, but will not benefit from DEP if it is enabled unless the appropriate Microsoft .NET Framework Service Pack has been installed.

Microsoft encourages application developers who redistribute the Microsoft .NET Framework to update to Microsoft .NET Framework version 1.0 Service Pack 3 or version 1.1 Service Pack 1, which take advantage of DEP.

What settings are added or changed in Windows Server 2003 Service Pack 1?

System-wide configuration of DEP

The primary difference in DEP behavior on Windows Server 2003 Service Pack 1 as compared to Windows XP Service Pack 2 (SP2) is that on the server operating system the default configuration is to protect all applications and services. In Windows XP SP2, DEP was turned on by default only for essential Windows operating system programs and services.

DEP configuration for the system is controlled through Boot.ini switches. Additionally, changes to System in Control Panel have been made to enable end users to easily configure DEP settings if they are logged onto the system as an administrator.

System DEP configuration settings apply only for 32-bit applications and processes when running on 32-bit or 64-bit versions of Windows. On 64-bit versions of Windows, if hardware-enforced DEP is available it is always applied to 64-bit processes and kernel memory spaces and there are no system configuration settings to disable it.

Windows supports four system-wide configurations for both hardware-enforced and software-enforced DEP.

DEP Configuration

Configuration Description

OptIn

(default for Windows XP SP2 and Windows XP 64-bit edition)

On systems with processors capable of hardware-enforced DEP, DEP is enabled by default for limited system binaries and applications that opt in. With this option, only Windows system binaries are covered by DEP by default.

OptOut

(default for Windows Server 2003 Service Pack 1)

DEP is enabled by default for all processes. Users can manually create a list of specific applications that do not have DEP applied using System in Control Panel. IT pros can use the Application Compatibility Toolkit to opt-out one or more applications from DEP protection. System Compatibility Fixes ("shims") for DEP do take effect.

AlwaysOn

This provides full DEP coverage for the entire system. All processes always run with DEP applied. The exceptions list for exempting specific applications from DEP protection is not available. System Compatibility Fixes ("shims") for DEP do not take effect. Applications that have been opted-out using the Application Compatibility Toolkit run with DEP applied.

AlwaysOff

This does not provide any DEP coverage for any part of the system, regardless of hardware DEP support. However, the processor will run in PAE mode with 32-bit versions of Windows unless the /noexecute=alwaysoff option is replaced with the /execute option in the boot entry.

Hardware-enforced and software-enforced DEP are configured in the same manner. If the system-wide DEP policy is set to OptIn, the same Windows core binaries and applications will be protected by both hardware and software-enforced DEP. If the system is not capable of hardware-enforced DEP, the Windows core binaries and applications will be protected only by software-enforced DEP.

Similarly, if the system-wide DEP policy is set to OptOut, applications that have been exempted from DEP protection will be exempted from both hardware and software-enforced DEP.

The four system-wide DEP configurations are controlled through Boot.ini switches. The Boot.ini settings are as follows:

/noexecute=policy_level

where policy_level is defined as AlwaysOn, AlwaysOff, OptIn, or OptOut.

Any existing /noexecute setting in the Boot.ini file is not changed when Windows Server 2003 Service Pack 1 is installed or if a Windows operating system image is moved across computers with and without hardware-enforced DEP support.

During installation of Windows Server 2003 Service Pack 1, the OptOut policy level is enabled by default unless a different policy level is specified in an unattended installation. If the /noexecute=policy_level setting is not present in the boot entry for a version of Windows that supports DEP, the behavior is the same as if the /noexecute=OptIn option was included.

End users who are logged on as administrators can manually configure DEP between the OptIn and OptOut policies using the Data Execution Prevention tab inside the Performance Options dialog box. The following procedure describes how to manually configure DEP on the computer:

To configure DEP settings
  1. Click Start, click Control Panel, and then double-click System.

  2. Click the Advanced tab. Then, under Performance, click Settings.

  3. Click the Data Execution Prevention tab.

  4. Click Turn on DEP for essential Windows programs and services only to select the OptIn policy.

  5. Click Turn on DEP for all programs and services except those I select to select the OptOut policy.

  6. If you selected the OptOut policy, click Add and add the applications that you do not want to use DEP with.

IT professionals can control system-wide DEP configuration with a variety of methods. The Boot.ini file can be modified directly with scripting mechanisms or with the Bootcfg.exe tool, which is included as part of Windows Server 2003 Service Pack 1.

For unattended installations of Windows Server 2003 with Service Pack 1, you can use the Unattend.txt file to prepopulate a specific DEP configuration. You can use the OSLoadOptionsVar entry in the [Data] section of the Unattend.txt file to specify a system-wide DEP configuration.

Per-application DEP configuration

For the purposes of application compatibility when DEP is set to the OptOut policy level, it is possible to selectively disable DEP for individual 32-bit applications. However, DEP is always enabled for 64-bit applications.

For end users, the Data Execution Prevention tab in System Properties can be used to selectively disable DEP for an application.

For IT professionals, a new application compatibility fix named DisableNX is included with Windows Server 2003 Service Pack 1. The DisableNX compatibility fix disables DEP for the program it is applied to.

The DisableNX compatibility fix can be applied to an application by using the Application Compatibility Toolkit. For more information about Windows application compatibility, see "Windows Application Compatibility" on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=23302.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft