Appendix F: SDL Requirement: No Executable Pages

Executing code from data code pages is a very common attack vector. The use of this technique is needed only in very limited scenarios. As a result, all programs and services should avoid this technique unless explicitly required. Having even one page marked EXECUTABLE in a process (other than dynamic-link libraries or DLLs) usually renders other security measures (such as /GS and /SafeSEH) useless for that process.

On This Page

Goals and Justification
Scope
Operating Systems
Product Services
Technologies
New Code and Legacy Code
Exceptions
Special Cases
Requirement
Compliance Measurement
Support Considerations

Goals and Justification

The Windows Exception Handling mechanism assumes that it is safe to dispatch exceptions to any address if they are not in a DLL but are still EXECUTABLE.

Given a stack buffer overflow, an attacker can overflow the nearest exception record on the stack (there is always at least one) and point it to an address in the page marked EXECUTABLE.

Because of the number of stack locations controlled by the overflow at the point the exception handler takes over, many possible op-code sequences would reliably deliver execution back to the attack-supplied buffer. One such sequence is {pop, pop, ret} (possibly interleaved with other instructions). It is also possible to leverage a sequence of op-codes that would produce an arbitrary memory-overwrite in a two-stage attack.

Because of the number of possibilities, it is very hard to prove that bytes on a page marked EXECUTABLE cannot be abused sufficiently to take control.

Scope

The following subsections specify the scope of the No Executable Pages requirement proposal.

Operating Systems

This requirement applies to Win32 and Win64 operating systems, but not to Windows CE or Macintosh.

Products/Services

This requirement applies to code that runs on customers’ computers (products), as well as to code that runs only on Microsoft-owned computers and used by customers (e.g. Microsoft owned and provisioned online services).

Technologies

This requirement applies to unmanaged (native) code such as C and C++.

New Code and/or Legacy Code

This requirement applies to both new code and legacy code.

Exceptions

• Sometimes it simply might not be possible to mark all pages as non-executable. Examples include digital rights management technologies and just-in-time (JIT) technologies that dynamically create code. For such cases, the following techniques can help make the pages safe:If your code uses VirtualAllocXXX APIs to allocate EXECUTABLE pages, load a dummy DLL and use one of its sections instead.

• Register a Vectored Exception Handler in the process and vet the chain of exception handlers to make sure none of them point to your EXECUTABLE pages.

• Randomize the address of the EXECUTABLE pages and/or randomize the starting offset of content within those pages.

Special Cases

Because marking a binary as “DEP compatible” (via /NXCOMPAT) changes how the operating system interacts with the executable, it is important to test all executables (.EXE) marked as /NXCOMPAT with a version of Windows that supports this functionality:

• Client software: Windows XP SP2, Windows Vista

• Server software: Windows Server 2003 Service Pack 1 (SP1) or Windows Server 2008

(Review the detailed description of the Data Execution Prevention (DEP) feature for specific details about how to use DEP on Windows Server 2003 SP1.)

All executables (.EXE) marked as /NXCOMPAT will be able to take advantage of Data Execution Protection. Dynamic-link libraries (.DLL files), or other code called by executables (such as COM objects) will not gain direct security benefits via /NXCOMPAT, but will need to coordinate enabling /DEP support with any executable files that might call them. Any EXE with /NXCOMPAT enabled that loads other code without /NXCOMPAT enabled may have the process fail unexpectedly unless the EXE and all of the other code that it calls (DLLs, COM objects, and so on) have been thoroughly tested with DEP enabled (linked with /NXCOMPAT option).

Requirement

Requirement: Do Not Use Certain VirtualAllocXXX Flags

If your code calls any of these APIs:

• VirtualAlloc

• VirtualAllocEx

• VirtualProtect

• VirtualProtectEx

• NtAllocateVirtualMemory

• NtProtectVirtualMemory

Do not use any of these flags:

• PAGE_EXECUTE

• PAGE_EXECUTE_READ

• PAGE_EXECUTE_READWRITE

• PAGE_EXECUTE_WRITECOPY

Requirement: Use /NXCOMPAT Linker Option

All binaries must link with /NXCOMPAT flag (and not link with /NXCOMPAT:NO) using the linker included with Visual Studio 2005 and later.

Compliance Measurement

Requirement: Do Not Use certain VirtualAllocXXX Flags

While no solutions exist to monitor the use of these APIs, project teams will be asked to examine project specifications for the use of these APIs and attest to their removal.

Requirement: Use /NXCOMPAT Linker Option

Measurement by Product/Service Team

Project teams will be asked to will be asked to attest to the use of this linker option.

Measurement by Security Advisors

This requirement is required to complete the final security review and use of this linker option should be confirmed before allowing the software to be released to manufacturing or the web (RTM/RTW).

Support Considerations

Requirement: Impact on Existing SDL Requirements

This requirement currently has some overlap with the Banned API requirement in that it describes some function calls that are prohibited. With the release of Windows Vista, this requirement is an even more important part of the Microsoft defense-in-depth strategy (in conjunction with Address Space Layout Randomization [ASLR] support in Windows Vista).

Requirement: Education and Training

Education reference materials currently available include:

• Data Execution Prevention

• Detailed description of the Data Execution Prevention (DEP) feature

Content Disclaimer