Appendix I: SDL Requirement: Heap Manager Fail Fast Setting

During the past few years, Microsoft added core defenses at the operating system level to help protect against some types of attacks. None of them are perfect, but when used together they can provide an effective defense. Examples include the firewall, the –GS flag, heap checking, and DEP (also known as NX). Generally, Microsoft introduces an initial version or subset of the defense and then augments it over time as developers and end users become accustomed to it.

A good example is Data Execution Protection (DEP). This feature was never enabled in Microsoft® Windows 2000 because it had no hardware support, but became available in Windows Server® 2003 as an unsupported boot.ini option. DEP was then supported for the first time in Windows XP Service Pack 2 (SP2), but set only for the system and not for non-system applications.

Another example, and the focus of this requirement, is the ability to detect and respond to heap corruption. In the past, there was no protection in the heap from heap-based buffer overruns. Microsoft then added metadata checking, primarily in the form of forward and backward link checking post block-free to determine whether a heap overrun had occurred. However, for application compatibility reasons, the mitigation was limited to preventing the arbitrary write controlled by a potential exploit from taking place, and the application was allowed to continue to run after the point the corruption was detected. Windows Vista™ includes a more robust mechanism: the application terminates when heap corruption is detected. This mechanism also helps developers find and fix heap–based overruns early in the development lifecycle.

This Heap Manager Fail Fast Setting requirement might cause reliability issues in applications that have poor heap memory management. However, the failing code is found immediately and can be fixed, which makes software both more secure and more reliable. Windows Vista has encountered only one such example in a third-party ActiveX® control.

This capability is enabled for some core operating system components, but not for non-system applications running on Windows Vista. This appendix outlines how to enable the option for non-system applications.

On This Page

Goals and Justification
Scope
Operating System
Products/Services
Technologies
New Code and Legacy Code
External Applicability
Exceptions and Special Cases
Requirement Definition
Compliance Measurement
Requirement: Measurement by Product/Service Team

Goals and Justification

Currently, even if corruption is detected in the heap manager, the process might continue to run successfully, depending on the corruption pattern, the data affected, and the usage. Some applications might hide memory-related bugs by handling exceptions, such as access violations, that are raised inside the heap manager. The goal is to find bugs early and create robust code. Therefore, certain critical operating system components must hard fail when heap corruption is detected. Also, any new application developed and tested on Vista should terminate on heap corruptions.

This requirement has two major benefits:

• The first benefit applies to development: With this requirement in place, problematic code is more likely to be found because the failure is immediate. Think of it as an “assert” on heap overrun. However, the code that performs heap-based memory allocation and manipulation must be tested correctly. The best method to find this class of bug is through fuzz testing.

• The second benefit is in deployment: If a bug is missed during development and a heap-based overrun exploit occurs, the exploit would become a denial-of-service issue rather than a potential code execution bug.

The requirement is a no-op on versions of the Windows operating system prior to Windows Vista  because the required setting is ignored.

Scope

The following subsections specify the scope of the Heap Manager Fail Test Setting requirement proposal.

Operating System

This requirement applies only to Win32.

Products/Services

This proposal 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 (services).

Technologies

This proposal applies to unmanaged (native) code such C and C++ but not to managed code such as C#.

New Code and/or Legacy Code

This proposal applies to new code but not to legacy code.

External Applicability

This proposal applies to external third-party ISV code.

Exceptions and Special Cases

There are no exceptions or special cases for new code.

Requirement Definition

Before you use any heap–based memory, you must add the following code to your application startup:

(void)HeapSetInformation(NULL, 
HeapEnableTerminationOnCorruption, 
NULL,
0); 

Microsoft also recommends that the code use the Low-Fragmentation Heap, which has been shown to be more resistant to attack than the “normal” heap in Windows. To use the Low-Fragmentation Heap, use the following code:

DWORD Frag = 2;
(void)HeapSetInformation(NULL, 
HeapCompatibilityInformation, 
&Frag, 
sizeof(&Frag));

You must add these function calls as early as possible on application startup. This requirement applies to all unmanaged .EXE files, but not to dynamic-link libraries (DLLs), which do not need to call this function.

Compliance Measurement

A product/service team can verify compliance in either of the two ways mentioned in the following requirement.

Requirement: Measurement by Product/Service Team

• Verify that the correct function is included in the main() function of the product and attest to its use.

  or:

• Run the application under a kernel debugger, issue the !heap -s command, and verify that the following text appears: Termination on corruption : ENABLED.

Content Disclaimer