In early June I’ve reported several security vulnerabilities in Nullsoft’s flagship product WinAmp to the devs. I received an amazing fast answer from the WinAmp Team acknowledging all reported security vulnerabilities. Only 5 days later I’ve received a private build including fixes for nearly all reported issues. Except one, but after sending a second exploit – poc the last issue has been fixed quickly too. All in all – and among all my already discovered and reported security flaws, the coordination process with Nullsoft was the most transparent and security-addicted, I ever had to deal with.

By the way…I gave them a tough timeframe of 14 days for a reliable security update (Google-Style baby 😀 ), which is very minimalistic compared to the code basis! At first this was only meant to test if a big vendor is able to hold such a timeline. And they did! They even produced it much faster to my surprise. Other vendors should start to take a leaf out of their work! Great job guys :-)!

Complete changelog.

Now the technical facts:

The first advisory [CVE-2013-4694] consolidates and describes multiple buffer overflow conditions in different libraries of  WinAmp. But both mentioned bugs are completely different and one of them is a lot more heavily weighted than the other.

The first bug in CVE-2013-4694 is “remotely” exploitable – CVSSv2 score of 7,5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)! But how and where to be careful ?

That’s all about it. A bad guy can send his victim a package containing an oversized directory name as the skin-name:


Finally…the applications uses a lstrcpynW (yep, it’s unicode based) call to basically work with the skin directory name to identify it in the folder – structure of WinAmp. Read this MS article to find out why this function could lead to the dangerous behaviour:


The application calls the vulnerable function @

which fills up the stack and finally RETs into the overwritten part of the stack:

…and that means control over EIP! But it’s a unicode based overflow with a limited scope of exploitation due to the nature of a unicode overflow…unless…someone finds a way to spray the heap or something like this 😉

The second bug isn’t as interesting as the first one, since it’s issued by entering an oversized string into one of the gui fields, which is a very unrealistic attack scenario…only interesting in sandbox-like environments or if the payload can be hidden using readable chars 😉


The second advisory [CVE-2013-4695] is a more complex vulnerability since it’s not a classic overflow scenario. It’s an invalid pointer dereference issue, which basically means that the attacker gets control over a specific part of a buffer which itself does not lead to any kind of code execution. But during the application flaw a pointer is called which dereferences a part of the controllable memory space…and THAT leads to real pwnage 😉

Also a complicated attack scenario, because the attacker has to copy an arbitrary links.xml somehow to the %appdata%\WinAmp directory. But after that, it’s quite easily to exploit. Some clicks here, some clicks there:


…and the application crashes. Deciphered:


The attacker has unicode control over ECX (00430043)! The content of ECX (more specific: the first 4 bytes “FF 30 51 E8”) are copied to EAX:

and EAX (now contains “E8 51 30 FF” due to little endian) is  pointer-called afterwards:

…leading to code execution. Another happy hacking-day :-)!

WinAmp v5.64 Fixes Several Code Execution Vulnerabilities (CVE-2013-4694, CVE-2013-4695)
Tagged on:             

Leave a Reply

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

Time limit is exhausted. Please reload CAPTCHA.