RSSHeap Overflow Vulnerability in WMP
By Scott M. Fulton, III | Published December 8, 2006, 3:55 PM
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.
Anyone else think WMP sucks? The interface is horrible. It's even hard to find "File->Open." Also, on vista it keeps slowing down on me (like it's in slow motion). They seriously need to redesign it and make it more user friendly.
Score: 0
The latest Windows Media Player 11 is NOT affected by this flaw
Score: 0
Thanks Microsoft Security. I can tell that the initiative you took 4+ years ago to make your platform more secure has really helped your customers!
/me watches botnets attack my leg.
Score: 0
flaws are in every programs. You just only have interest to find them...
Score: 0
The article even points at steps WMP does take to try to prevent overflows. The developer has simply overlooked one possible method of writing a URL. It's easy to do, and it's taken many years for even security researches to spot the potential problem. I bet there are lots of media player apps that don't even do this much sanity checking.
Sometimes it's appropriate to lay the smack down on Microsoft. I don't think this is one of those times.
Score: 0