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 […]

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