Heap Overflow Vulnerability in WMP

Microsoft yesterday officially acknowledged -– albeit two weeks after its discovery –- that a vulnerability in Windows Media Player found by security research team eEye Digital Security could indeed become an exploitable problem. Thankfully, no exploit seems to have turned up yet.

As an eEye report on November 22 indicated, a function that handles the XML-based ASX playlists in, apparently, all known versions of Media Player that support them (perhaps, based on our research, back to version 6.4 for Windows 95 in 1999) can be fooled into allocating too much heap memory to handle a string that should contain the URL of a media file included in the playlist. It isn’t much –- the entire overflow could be three or four bytes, maximum -– but the fact that it is an overflow could create an exploitable condition, eEye points out.

Heap overflow problems with ASX files in Media Player have been discovered almost since version 6.4 was first released. This particular one, though, may have been hiding in plain sight, which is one of the places eEye eventually looks.

As the firm’s bulletin describes, the XML element that contains the URL of the media file is REF. It uses an HREF attribute that’s set to the URL, just like with an A tag in HTML. The first part of a URL is always the protocol name, such as http://. In the event that protocol is omitted or isn’t recognized, Media Player assumes the media file is a streaming URL, and automatically attaches mms://. That’s a six-character appendage.

Assuming Media Player has to make this substitution, then when it allocates the heap memory for the name, it counts the number of characters in the URL that was supplied, then adds six for the appendage. Since no acceptable protocol names are shorter than three characters – that is, shorter than “mms” – then you’d think this would be fine.

But suppose somebody were to pass an illegitimate protocol that was shorter. Thankfully, as part of its diligent type checking, WMP checks to make sure that no protocol supplied can be shorter than three characters. So you can’t write REF HREF="bn://try_this_one.avi" into an ASX file and get away with it; WMP will filter it out.

So what’s the problem? An eEye engineer discovered that the parser that looks at the supplied URL first to replace character codes with characters, functions after the protocol filter. So if you enter REF HREF="b%6e://try_this_one.avi", the seemingly four-character protocol name would pass the filter first, then the %6e would get replaced with n and the URL would be in violation. WMP would have allocated two more bytes on the heap than it actually needed, triggering the overflow.

Microsoft’s Security Response Center says it’s also investigating the possibility of other ways in which the same trigger could possibly be exploited. No exploits are currently known, though eEye says it believes exploitability is possible. Meanwhile, Secunia rates the overflow as “Highly Critical.”

Other than simply avoiding opening ASX playlists altogether, one other approach eEye suggests is to use a different media player for ASX.