Old dbghelp and an old exploit…

Post moved from OpenRCE, original date: Friday, January 30 2009

Recently I’ve came across some “strange” problems during loading some executables into OllyDbg. After loading the file, OllyDbg just crashed without any error. During a quick research I’ve figured out that the problem lays in the extension of the loaded file. In fact, the problem laid in the old version of dbghelp.dll (5.1.3590.0). I’ve asked google if “she” (or “he”, who knows) knows something about this bug, and that was a good choice. I’ve found a discussion on tuts4you forum:

hxxp://forum.tuts4you.com/index.php?showtopic=16445

and a link to an exploit on milw0rm:

http://www.milw0rm.com/exploits/6031

As you can read, it was related to “export name buffer overflow vulnerability”. My problem was different, but debugging OllyDbg lead me to the call to SymLoadModule at the same place like in the mentioned exploit. Further debugging revealed that my problem is related to the wrong use of _splitpath function from msvcrt.dll. Calling tree looks like this:

SymLoadModule (exported)
-> SymLoadModule64 (exported)
-> SymLoadModuleEx (exported)
-> InternalLoadModule
-> load
-> GetDebugData
-> FileNameIsPdb
-> msvcrt.splitpath

function FileNameIsPdb has a local variable:

char _str_extension[20];

which is passed to the splitpath, and if our prepared file extension is longer than 20 bytes it overwrites values on the stack, next 8 bytes overwrite some local variables, and finaly next 4 bytes overwrites the return address:

extension: ".dll1234567890qwertyuiopasdfxxxx"

it is not enough to crash OllyDbg though (for exploiting it should be sufficient), because there is SEH that can deal with this stack corruption. I figured out that overwriting another 26 bytes should crash OllyDbg, so the file extension should look like this:

"sample.dll1234567890qwertyuiopasdfxxxxlzxcvbnmQWERTYUIOPASDFGHJK"

If someone has not updated dbghelp.dll in the olly directory, we can use this method as a simple anti-debug. We don’t need to rename executable to such form, we can dump a sample dll (with malformed extension) on the disk during the execution of the program, and just load it with LoadLibrary function. Development of an exploit could prove to be problematic because of limitations of charset that can be used to craft filename.

This bug cannot be applied to newer versions of dbghelp.dll.

Original paper at: http://rewolf.pl/stuff/rewolf_dbghelp.txt

Leave a Reply

Your email address will not be published. Required fields are marked *