I recently took a look at the stack-based overflow in SureThing CD Labeler Deluxe v5.1.616 reported by Parvez Anwar.  The issue was reported in the handling of playlist files (.m3u/.pls/.xml/.wpl/.txt).  Not knowning much about the format of a .m3u file I went looking for a spec.  The first description provided for a simple playlist file described a very basic list of filenames and locations seperated by newline.  Nothing fancy at all.

Creating an .m3u with an overly long string on the first line crashed the application in short order.  Upon examination in Immunity Debugger we show that we have caused an exception.  A quick look at the SEH chain shows that we have overwritten a handler at 266 bytes in (267 and 268 being “BB”).

One thing to notice however is that our input has been unicode expanded by the application.  This creates an interesting challenge in that instead of controlling all 4 bytes of our handler address we control 2, seperated by \x00.  Awesome.

At the time this occurs we don’t have another register pointing to the buffer, but we do have several pointers on the stack.  This makes locating a unicode friendly address to use a real easter egg hunt as instead of finding an address of 0x00nn00nn that we use as JMP, we actually need a 0x00nn00nn with a chain of instructions that can get a register right with God as well as allowing us to make it there.  Fairly sure this is doable and with some Venetian shellcode, likely a viable exploit, but potentially quite time-consuming.

OSVDB 55297

Anyone care to share quicker ways of dealing with locating unicode friendly workable instruction chains?

Exploitation 0day, OSVDB