May 19, 2012

This note describes two ways to verify the heap manager settings if the termination on corruption flag is enabled. Both of them require Windbg.

Execute the below command to print the value of the disable break on failure cookie. If the value is zero the termination on heap corruption flag is set, otherwise it's unset. For more details about this see the previous post.
0:031> db ntdll!RtlpDisableBreakOnFailureCookie L4
77230098 aa cb 7f 69 ...i

Another way is to execute the following command to print if the termination on heap corruption is enabled.
0:031> !heap -s
LFH Key : 0x726d2f4c
Termination on corruption : DISABLED

I checked the popular browsers (32-bit version) if they have the termination on heap corruption feature enabled. Here is the result.

Internet Explorer: ENABLED
Chrome: ENABLED
Mozilla Firefox: DISABLED

I asked Mozilla what's the reason to not enable this mitigation but haven't heard back from them so far.

As it can be seen, if HeapEnableTerminationOnCorruption is specified, [RtlpDisableBreakOnFailureCookie] is set to zero.

As the next step, a simple application that intentionally corrupts the heap was created. I placed a breakpoint to see what happens when [RtlpDisableBreakOnFailureCookie] is accessed.

When the breakpoint hit, I got the code snippet below. The caller function was RtlpReportHeapFailure implying heap failure, so I have reason to think the code snippet is not reached unless heap corruption is encountered.

RtlpGetModifiedProcessCookie returns with a cookie value, and I observed that value was the same to the initial value of [RtlpDisableBreakOnFailureCookie].

Save the configuration and test if it works. Open a project that builds an executable file. Select Tools, then select Windbg to start the debugger. In the command window type .open example.cpp to load the source code. The source window should pop up with the source file in it. Move the cursor in the source window and press F9 to place a breakpoint.

May 6, 2012

I'm describing a way to create an extension for Windbg in Visual Studio 2010 Express. The description is applied for the 32-bit version of Windows debugger but the same steps could be easily adopted for the 64-bit debugger. If you're not interested in setting up a Visual Studio configuration, but want a sample extension, you can download one from CodePlex. That one was created using the steps below.

Create an Empty Visual C++ Project and save the solution as sampext.
Add sampext.cpp to the project with the following content.

#include "sampext.h"

EXT_DECLARE_GLOBALS();

EXT_CLASS::EXT_CLASS()
{
}

Add sampext.h to the project with the following content.

#pragma once
#include "engextcpp.hpp"

class EXT_CLASS : public ExtExtension
{
protected:

public: EXT_CLASS(); EXT_COMMAND_METHOD(ver);
};

Add ver.cpp to the project file with the following content. This file contains the implementation of the sample command.

May 2, 2012

Microsoft introduced a new compiler defense in Visual Studio 11 Beta that is to mitigate simple dangling pointer bugs. When the memory has been freed using the delete operator the pointer is set to 0x8123.

I asked Microsoft about this issue, and they confirmed that the /sdl flag doesn't work in this scenario. The reason is that in line delete [] arr[0], the expression arr[0] passed into the delete call is dereference. VS11 provides initial support for pointer sanitization when "the expression passed into the delete call does not involve a dereference." For more info see their blog post.