Some days ago, we posted a proof of concept published by Luigi Auriemma outlining Multiple Denial Of Service Vulnerabilities in Winamp. Unlike most submissions we receive, the PoC posted by the author didn’t contain a script to replicate the attack, but only contained files ready to be loaded into Winamp.
After some days we got an e-mail from ryujin…
anybody wants to have a look at http://www.exploit-db.com/exploits/15248/ ?
The stack overflow (see mtm screenie) looks promising ;)
fdisk, Mighty-D and dijital1 decided to take a crack at it.
Our first task was to understand the Multi Track Module (MTM) file from the original advisory, also available here. We connected a debugger to Winamp and triggered the bug by viewing the file’s information.
This was encouraging. We had a direct EIP overwrite with a couple of registers pointing to a buffer that we controlled. One key point to notice from the screenshot below are the CRLF sequences that are being inserted into our buffer. More on this later :-)
The next step was to create a skeleton exploit that we could use for testing.
The first hurdle was building a properly formatted MTM file. After some reading about the MTM file format here, we modified a valid MTM file using hexedit.
Below is the resulting skeleton exploit.
Using the above code, we verified that still had a direct EIP overwrite and that EDI and ESP were pointing to the buffer we control which was nice. We had 40 bytes of clean space between each of the “CRLF” sequences which doesn’t give us enough space to execute a bind or reverse shell, but it’s enough for a traditional egghunter. From this point we thought that completing the exploit should be fairly straight forward.
Initial testing of the egg hunter showed that all characters between 0x2 and 0xf along with a few others, were bring translated to a space (0x20). This ends up mangling the egg hunter code as shown in the next screenshot.
At this point we started sending very long buffers in order to find some areas in memory to hold our shellcode. As a side effect, we found that we could also get control of execution via an SEH overwrite. Finding a “good” address to overwrite the SEH handler with proved to be more difficult than usual. Most of the modules compiled without safeseh were mapped at addresses containing characters that were also replaced by spaces (0x20).
Here we see that the address that we sent to overwrite the SEH (0x100019F7) was being converted to 0x202019F7.
After digging a bit more we were also able to get code execution through SEH. See below (works but the shellcode needs to be fixed).
So we now had 2 potential ways to get code execution. The problem still remained that any payload inserted before or after the EIP or SEH overwrite would be corrupted by the CRLF sequences. Time for some custom assembly. David Mora (a.k.a Mighty-D) wrote an assembly sequence to walk through the payload and replace the CRLF bytes with the original shellcode bytes. To avoid damage from CRLF sequences, the EBX register was used, since the 0x0D 0x0A represent an OR operation over the EAX register can be considered as a NOP equivalent instruction.
The buffer was arranged such that upon completing the main payload repairs, EIP would execute our bind shell payload.
[NOP Sled] — [EIP Overwrite with JMP ESP] — [ESP Points Here] — [Payload Repair Assembly] — [Repaired Bind Shell Payload]
Flow of Execution —->
The result of the collaboration is below and at this link: Winamp 5.5.8 (in_mod plugin) Stack Overflow Exploit.
Special thanks to ryujin for bringing this up and to all the EDB Dev Team.
Note: a second exploit for this vulnerability was posted at http://www.exploit-db.com/exploits/15312/