Message-Id: <C4F2EDD3-9937-4EAB-8466-A26256C1D3DE@beskerming.com>
Date: Fri, 8 Dec 2006 17:23:02 +1030
From: Sûnnet Beskerming <info@...kerming.com>
To: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: ASX Playlists and Jumping to Conclusions

Hi list(s),

The recent coverage of ASX Playlist issues seems somewhat strange.   
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  
handling of 'ref href' URIs.  A CVE entry (CVE-2006-6063 - though  
this only identifies the .m3u method of exploiting the vulnerability)  
appears around the same time, and reporting is carried by the usual  
third parties.  With no fix present, this remains an effective 0-day  
(plus, with existing malware targeting .asx files it could make for  
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  
overflow demonstrated the day before, only with the exploit payload  
removed and replaced with a bunch of 'A's, and fails to draw much  
interest from third parties.  It isn't until eEye publishes data on  
this issue (and increases the perceived threat posed) on their 0-day  
reporting / information site that it attracts some attention from  
other reporting parties (such as FrSIRT on 7 December), though uptake  
is slow.

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

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

Criticism has been recently levelled against third party reporting  
bodies for failing to adequately investigate reports (after one of  
the recent MoKB OS X corrupted .dmg file handling errors), and the  
way that information is flowing between, and being distributed by,  
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  
handling of malicious .asx (and other content types) data passed via  
'ref href' that can lead to arbitrary code execution.
  - There is a known DoS targeting WMP that is exploited via a long  
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  
arbitrary code execution
  - The advice to replace WMP as the default .asx filetype handler  
can lead to an increased security risk if the replacement application  
is XMPlay (accepting arbitrary code execution in an effort to avoid a  
DoS).


Sincerely,

Carl Jongsma
info@...kerming.com
Sûnnet Beskerming Pty. Ltd.
Adelaide, Australia
http://www.beskerming.com

Sûnnet Beskerming Pty. Ltd.

Established in mid 2004, Sûnnet Beskerming Pty. Ltd. is the sister  
company to Jongsma & Jongsma Pty. Ltd., and was formed to develop and  
commercialise advanced Information Security research. Sûnnet  
Beskerming Pty. Ltd. is an Information Security specialist and, in  
conjunction with the tools developed in house, provides total  
security solutions and services, from the perimeter to internal data  
stores, including web application security and security testing and  
analysis.

Powered by blists - more mailing lists