Winamp "NowPlaying" Unspecified Vulnerability: The Details

Hey,

Since no information has yet been published about a vulnerability I recently discovered in Winamp, and the issue has raised some interest, here are the details.

Recently, while listening to some music via Winamp (my favorite media player), I recalled an old Winamp Buffer-Overflow vulnerability found by Leon Juranic in 2005.
Leon found that since Winamp didn't expect long inputs in mp3 id3 tags, a buffer-overflow attack was possible by playing specially crafted mp3 files with lengthy tags.

Knowing that Winamp uses an embedded browser in various places, I decided to take a closer look at it and see what could be done... ;)
My aim was to inject JavaScript into the context of the embedded browser, and examine the ramifications. I suspected that the mp3 id3 tags might be a good place to start, and therefore concentrated on the "Now Playing" feature.

Winamp's "Now Playing" feature uses an embedded browser to present information about the currently played media file. When the user plays a media file, some of the file's metadata is embedded into the HTML that the embedded-browser displays.

It turned out that if the metadata (id3 tags) of the mp3 file contained a JavaScript payload, Winamp failed to sanitize it and therefore injected it intact into the embedded browser – a feasible XSS exploitation scenario.

A (seemingly) normal mp3 file.


Adding "A song.mp3" to Winamp's playlist


Playing the poisoned mp3 file...
Attacker-controlled JavaScript code is executed.

Furthermore, due to the integration between the embedded browser and the Winamp application, this script injection vulnerability has some unique characteristics.

In many cases, Desktop applications that utilize IE embedded browsers render the HTML content in a highly privileged zone called "My Computer Zone". This zone allows the programmer to perform a wide range of actions on the computer and thereby to "interact" with the hosting application. The downside of this (fairly common) approach is that if the application is susceptible to XSS, a malicious attacker might be able to exploit it and gain full system control over the victim's system. (Aviv Raff did some great work in this field, "Skype cross-zone scripting vulnerability" being a well-known example.)

Winamp's programmers were probably aware to this security threat and therefore chose a different approach. Instead of creating and loading a local file that contains all the relevant data (e.g. data about the song retrieved from the Internet and data originated from the id3 tags of the mp3 file) in a privileged security zone, Winamp loads the embedded browser with a page located in http://client.winamp.com (Internet URL - non-privileged zone).

At first glance, this seems to make an XSS attack innoxious, because of Same Origin policy. However, in order to implement the required interaction between the Winamp application and its embedded browser, a bridge from the browser to Winamp was created in the form of window.external. That means that JavaScript code (which is attacker-controlled due to the XSS vulnerability I found) could trigger various internal functionalities of Winamp which were not intended to be invoked by a remote attacker.

The attack could then be taken one step ahead, by trying to identify functions that are susceptible to memory-based attacks or logical attacks (Reading/Writing of information from/to the victim's host and even gaining full system control in the form of executing commands).

Since the attack is almost undetectable (the malicious JavaScript within the id3 tags can be padded with white spaces and therefore rendered invisible to the Winamp user when the malicious mp3 file is played), such a poisoned file could be easily distributed via P2P networks, resulting in a large-scale (and possibly silent) attack against Winamp users.

The id3 tags editor of Winamp doesn't give indication for the attack (due to white spaces padding)...

Going to the end of the Artist text box reveals the (potentially malicious) JavaScript code

Acknowledgments:

I would like to thank Winamp's team for their quick responses and the efficient way in which they handled this security issue.

Comments

[Leon]

I was reading some Watchfire blogs, and came across this one :-)... It took me ~2 weeks after initial bug discovery, before I figured how to exploit that Winamp overflow. :)

[Yair Amit]

Hey Leon,

It was a very cool attack! ;)
What are you up to these days?