Quick & Dirty - MediaCoder .m3u stack overflow

Following thispublic exploit for MediaCoder Audio Edition I decided to take a look at it, and if possible, try to exploit it under Windows 7. My surprise comes as in the latest available version (MediaCoderAE-0.7.3.4610) it still wasn't fixed. Since the development team doesn't seem to care much about it getting fixed anyway, I'll make a quick write-up of what's it about. The bug in question is a fairly handbook example of a stack based buffer overflow. The binary (and some of it's libraries) don't support neither DEP nor ASLR which puts a smile in our face (or not, considering we are in 2010) right away. If we supply a .m3u file with a large amount of data, we will end up writing past the boundaries of the buffer. Quick & Dirty. M3U. 10K 'A's. Let's take a look at the guilty.

.text:00416080 mov cl, [eax]
.text:00416082 mov [edx], cl
.text:00416084 inc eax
.text:00416085 inc edx
.text:00416086 test cl, cl
.text:00416088 jnz short loc_416080Nothing surprising in here. To exploit this issue we will fill the buffer with about 20k bytes of data overwriting the SEH (you guessed it, not /SafeSEH either :-) entry pointing to a pop/pop/ret sequence and executing it writing data past the stack boundary. Since I mentioned that the exploit was intented to work in a Windows 7 enviroment, system dll's where randomized. This left us with the following list:

Some of this libraries are loaded at runtime and their base addresses do overlap, thus, we end up getting unpredictable base addresses in them. Therefore, with further filtering, we are left with 2 libraries that are loaded at the beginning of the process and thus are guaranteed to be located at a predictable location.

• mccommon.dll
• libiconv-2.dll

A quick analysis in both memory sections exposed 0x66017187 as a good candidate. Nothing new in this case then, grab a copy of the exploit over here. Tested under Windows 7 Professional 32bit.