Re: Understanding Windows Heap Overflows

[Matt Conover <mconover () gmail com>]

Also newer versions of windbg can be configured to prevent this:
"Processes created by the debugger behave slightly differently than they
would under normal conditions. Instead of using the standard heap API,
processes created by the debugger use a special *debug heap*. On Microsoft(r)
Windows XP and later versions of Windows, you can force a spawned process to
use the standard heap instead of the debug heap by using the
_NO_DEBUG_HEAP environment
variable<mk:@MSITStore:C:\Program%20Files\Debugging%20Tools%20for%20Windows\debugger.chm::/hh/Debugger/r12_cmdline_067c8775-4c54-4443-b4f5-3233dfa9d00f.xml.htm>or
the
*-hd* command-line
option<mk:@MSITStore:C:\Program%20Files\Debugging%20Tools%20for%20Windows\debugger.chm::/hh/Debugger/r12_cmdline_8186a614-5656-427b-82ab-2a4899123d95.xml.htm>
"

On 10/19/05, Dave Korn <dave.korn () artimi com> wrote:
> Apologies for resurrecting an old thread, but I just thought it worth
> mentioning:
>
> pbb wrote:
>
> > With the example given, I couldn't get it to do anything, no 4 byte
> > overwrite. I seem not to be able to step through a overwrite of the
> > UEF in visual studio, I read somewhere it was because the debugger
> > overwrites the Exception handler already so the original pointer isn't
> > called thus the overflow overwrites the wrong address.
> >
> > I was able to get the SP2 one to work out of visual studio but not
> > within, does anyone have a way around this issue.
>
>
> Using WinDbg
> (http://www.microsoft.com/whdc/devtools/debugging/default.mspx) instead
> worked for me. I was using it for just this purpose at the time of the
> dcom
> (blaster) bug; I was able to single step all the way through the user
> exception dispatcher code, watch it unwind the entire exception handler
> chain and eventually end up at the UEF.
>
> Start with "bp ntdll!RtlDispatchException" and take it from there!
>
>
> cheers,
> DaveK
> --
> Can't think of a witty .sigline today....