IBM Application Security Insider

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.

Automated Crawling & Security Testing of Flash/Flex Web Applications

Ronen Bachar, from our own IBM Rational AppScan team, gave a presentation on the (*hot*) subject of automated Flash/Flex application security testing, at the recent OWASP IL conference that was held last week (I have a strange feeling of a Deja-Vu).

The presentation gives a high level overview of Flash, Flex and the AMF protocol, and dives into some gory details (although some gore is missing from the online presentation) regarding the challenges and possible approaches for performing automated crawling and security testing of web applications that were built using these technologies.

 

And while we're on the subject of Adobe Flash & Flex web applications - if you happen to be in New York next week for the OWASP AppSec conference, be sure to attend another presentation by our team (Adi Sharabani & Ayal Yogev), on the subject of Flash Parameter Injection.

Blackbox vs. Whitebox - OWASP IL Presentation

Adi Sharabani and Yinnon Haviv, both from IBM Rational Application Security, gave a very interesting presentation on the subject of Blackbox and Whitebox application security scanners, at the recent OWASP IL conference that took place last week.

Since our team is working on both technologies, we believe that we can provide an unbiased and thorough overview of the difference between both scanning approaches, and also to point out how they complement each other.

You can view the presentation here, or download it from the OWASP IL conference site (will soon be uploaded).

We will soon upload another OWASP IL presentation given by our own Ronen Bachar, which talks about the challenges and solutions for automated Flash/Flex application security testing, so stay tuned!

QuickTime patched

Apple has just released a fix to a vulnerability I reported to them a while ago (go update to 7.5.5).

Quoting apple (http://support.apple.com/kb/HT1222)

"CVE-ID:  CVE-2008-3624
Available for:  Mac OS X v10.4.9 - v10.4.11,
Mac OS X v10.5 or later, Windows Vista, XP SP2 and SP3
Impact:  Viewing a maliciously crafted QTVR movie file may lead to an
unexpected application termination or arbitrary code execution
Description:  A heap buffer overflow exists in QuickTime's handling
of panorama atoms in QTVR (QuickTime Virtual Reality) movie files.
Viewing a maliciously crafted QTVR file may lead to an unexpected
application termination or arbitrary code execution. This update
addresses the issue through improved bounds checking of panorama
atoms.

In a nutshell, this vulnerability is caused by a Sign Extension bug which leads to a heap overflow.

I would like to spit out a few words regarding sign extension bugs because I feel they are somewhat overlooked

What are sign extension bugs?

Let's take a look at a vulnerable code snippet:

 

   1:  char target[0xFFFF];

   2:  char src[0xFFFF];

   3:  ....

   4:  short x = <user input>;

   5:  long y = x;

   6:  memset(target, 1, y);

At line [4], x is defined as short which is assigned by user input.
At line [5], x is extended into long, and copied to y.
At line [6]. y is used as the length parameter for the memset call.

So where is the overflow?

To begin with, for the sake of simplicity, short is 16bit and long is 32bit.

Since we are dealing with signed numbers, the extension from short to long must not affect the sign of the input.

If x is above or equals to 0x8000 (-32768), the most significant bits of y are set (e.g: 0x8000 becomes 0xFFFF8000).  Under x86, this is done by the  MOVSX instruction (As opposed to MOVZX which is used for extending unsigned numbers).

When there is a sign/unsign mismatch, a negative signed number is effectively considered as a very large unsigned number. This exactly what happens in the memset function as the length parameter is expected to be unsigned.

Exploitation:

Set  x to a value above or equal to 0x8000, This will make y a very large unsigned number, and cause memset to overflow the given target.

Best practice:

Don't mix up signed and unsigned numbers. Passing a signed number to a function which receives an unsigned one is prone to errors.

In order to fix the code snippet above one should define x and y as unsigned numbers instead of signed ones. This will make the compiler use the MOVZX instruction instead of MOVSX, making it impossible for a malicious user to assign a value larger than 0xFFFF to the long variable.

 

Acknowledgments:

I would like to thank Apple Product Security team for their quick responses and the efficient way in which they handled this security issue.