[ad]<\/p>\n
Oh look! Another 0-day in Windows…this time in Media Player, there was a few in Word lately and the latest thing that just hit is an XSS flaw in PDF files online.<\/p>\n
I’ll report more on those later.<\/p>\n
The Windows Media Player library WMVCORE.DLL contains a potentially exploitable heap buffer overflow in its handling of “REF HREF” URLs within ASX files. If the URL contains an unrecognized protocol (only “file”, “ftp”, “http”, “https”, “mms”, “mmst”, “mmsu”, “rtsp”, “rtspt”, and “rtspu” appear to be recognized), the function at 7D7A8F27 in WMVCORE.DLL version 9.0.0.3250, and at 086E586E in WMVCORE.DLL version 10.0.0.3802, will create a copy of the string in which the protocol is replaced with “mms”. A heap buffer is allocated, the string “mms” is copied into it, and then everything after and including “:\/\/” in the “REF HREF” URL is concatenated using wcsncat.<\/p><\/blockquote>\n
So what out what you are streaming..please! Or alternatively use something decent like Winamp.<\/p>\n
Unfortunately, the heap buffer for the new “mms” URL is allocated to the size of the “REF HREF” URL, and even more unfortunately, the length of the input string being passed to wcsncat is supplied as the character count, effectively causing wcsncat to behave identically to wcscat. As a result, a two- or four-byte heap overflow is possible if the “REF HREF” URL features a protocol shorter than three characters (the length of “mms”).<\/p>\n
Single-letter protocols (such as “a:\/\/”) are rejected, but this restriction can be circumvented by encoding the protocol (“%61:\/\/”), thereby making a four-byte overflow possible.<\/p>\n
Exploitability due to the corruption of the adjacent heap block’s header is assumed likely but research is ongoing.<\/p><\/blockquote>\n
As far as I know there’s no current exploit for this, but it is a possibility.<\/p>\n
<\/p>\n