=?ISO-8859-1?Q?S=FBnnet_Beskerming?=
14/12/06, 10:44
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.
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.