Hi list(s),

The recent coverage of ASX Playlist issues seems somewhat strange. =20
For the uninitiated, here is a quick wrapup:

XMPlay ASX buffer overflow PoC code posted to milw0rm - 21 November

This PoC demonstrated an exploitable buffer overflow condition in the =20=

handling of 'ref href' URIs. A CVE entry (CVE-2006-6063 - though =20
this only identifies the .m3u method of exploiting the vulnerability) =20=

appears around the same time, and reporting is carried by the usual =20
third parties. With no fix present, this remains an effective 0-day =20
(plus, with existing malware targeting .asx files it could make for =20
interesting real-world use).

Windows Media Player DoS code posted to BugTraq - 22 November

Oddly, this code represented an almost exact duplicate of the buffer =20
overflow demonstrated the day before, only with the exploit payload =20
removed and replaced with a bunch of 'A's, and fails to draw much =20
interest from third parties. It isn't until eEye publishes data on =20
this issue (and increases the perceived threat posed) on their 0-day =20
reporting / information site that it attracts some attention from =20
other reporting parties (such as FrSIRT on 7 December), though uptake =20=

is slow.

Leaving Chinese Soup's critique (BugTraq) of eEye's analysis aside =20
(why they haven't identified on the XMPlay vulnerability is another =20
question), users need to be aware that if they replace WMP with =20
XMPlay as the default handler of .asx content, then they are =20
potentially creating a much riskier environment than if they accept =20
the current DoS risk against their platform.

If this particular code release had appropriate accompanying =20
documentation, it would be possible to work out whether it is a =20
derivative of the earlier code, or fortuitous timing on something =20
found independently.

Criticism has been recently levelled against third party reporting =20
bodies for failing to adequately investigate reports (after one of =20
the recent MoKB OS X corrupted .dmg file handling errors), and the =20
way that information is flowing between, and being distributed by, =20
third party reporting bodies in this case is showing similar patterns.

In summary:
- There is a known 0-day targeting a vulnerability in XMPlay's =20
handling of malicious .asx (and other content types) data passed via =20
'ref href' that can lead to arbitrary code execution.
- There is a known DoS targeting WMP that is exploited via a long =20
string passed via 'ref href' and using the .asx media type
- There has been no proven link between the two disclosures
- It has yet to be shown that the WMP vulnerability leads to =20
arbitrary code execution
- The advice to replace WMP as the default .asx filetype handler =20
can lead to an increased security risk if the replacement application =20=

is XMPlay (accepting arbitrary code execution in an effort to avoid a =20=

DoS).


Sincerely,

Carl Jongsma
info@beskerming.com
S=FBnnet Beskerming Pty. Ltd.
Adelaide, Australia
http://www.beskerming.com

S=FBnnet Beskerming Pty. Ltd.

Established in mid 2004, S=FBnnet Beskerming Pty. Ltd. is the sister =20
company to Jongsma & Jongsma Pty. Ltd., and was formed to develop and =20=

commercialise advanced Information Security research. S=FBnnet =20
Beskerming Pty. Ltd. is an Information Security specialist and, in =20
conjunction with the tools developed in house, provides total =20
security solutions and services, from the perimeter to internal data =20
stores, including web application security and security testing and =20
analysis.