-----BEGIN PGP SIGNED MESSAGE-----

===========================================================================
             AUSCERT External Security Bulletin Redistribution

                  ESB-2002.212 -- eEye Security Advisory
                 Macromedia Flash Activex Buffer Overflow
                                6 May 2002

===========================================================================

        AusCERT Security Bulletin Summary
        ---------------------------------

Product:                Flash ActiveX OCX
Vendor:                 Macromedia
Operating System:       Windows
Impact:                 Execute Arbitrary Code/Commands
Access Required:        Remote

- --------------------------BEGIN INCLUDED TEXT--------------------

Macromedia Flash Activex Buffer overflow

Release Date:
05/02/2002

Severity:
High (Remote code execution)

Systems Affected:
Systems with Flash Activex OCX Version 6, revision 23
(Possibly older versions)
This includes most installations of Windows.

Description:
All users of Internet Explorer are potentially affected because this is a
Macromedia signed OCX. We advise them to upgrade their Flash version
immediately to version 6, revision 29 (see the Vendor Status section below).

This is an unusual advisory in a number of ways. 

One, it was found while investigating an access error encountered during
normal web surfing, which was suspicious. Within a few hours we had
confirmation on multiple Operating Systems that this was an exploitable
condition that overwrote EIP.

Two, while testing the new version from the vendor’s site, we learned
they were announcing a new build later in the day. They asked us to try
the new build and confirm that the new build fixed the issue. Testing the
link later that night confirmed the link we used to install the OCX now
had the fixed, latest version.

In this, we congratulate Macromedia for: locating the bug, fixing it, and
releasing a new build in a timely fashion. This truly shows that they are
dedicated to building secure products -– kudos.

However, because there are vast amounts of outdated signed Flash OCX’s in
use worldwide, the potential exploit risk is very high –- thus, we are
releasing this advisory.

Furthermore, this issue was found in the wild, and it is not safe to
assume that others could not detect it and utilize the OCX weakness with
malicious intent.

A vulnerability in the parameter handling to the Flash OCX, which could
lead to the execution of attacker supplied code via email, web or any other
avenue in which Internet Explorer is used to display html that an attacker
can supply. This includes software which uses the web browser ActiveX.

Example:

<OBJECT classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000">
<PARAM NAME=movie VALUE="http://www.notthere8979873.com/notthere.swf?AAA
[...unstated, but fixed number]XXXXXXXX">
</OBJECT>

Where X overwrites the EIP consistently across Windows platforms.

Technical Description:

Flash.OCX is an ActiveX object installed with Internet Explorer, and is
used to display Flash objects on the web.

Proper bounds checking is not in place in the "movie" parameter which
overwrites EIP at an unsaid, but fixed number of bytes across Windows
platforms.

Because the OCX is signed by Macromedia: there is a chance the older
ActiveX could be used against people without Flash; people whom have an
older version of Flash not affected may be forced to "upgrade" to the
affected version; and, of course, those with the affected versions need
to upgrade lest the exploit works out of the box on them.

There has been considerable debate about legacy ActiveX objects that
have exploits within them. In general, if someone uses the codebase
parameter to point to an affected version of the ActiveX, the system
will first try and grab the ActiveX from Microsoft's ActiveX store on
the web. Then, it will try the ActiveX specified in the codebase tag
by the malicious user.

We do not believe this method is fool-proof.

We do not believe the method is full proof because of the potential
of the ActiveX storehouse check failing and because of the potentiality
for the ActiveX to be called by other methods. (At least a few potential
other methods are in the RFC for applets and objects).

However, the other option of setting the "kill bit" for the affected
ActiveX and reassigning the fixed ActiveX version with a new classid is
only a suggestion we will make in this case. We do not believe it is
necessarily mandatory.

Risk should be mitigated to a satisfactory level when users upgrade to
the new OCX.

Vendor Status:
Visit Macromedia's site to get the latest Flash ocx to eliminate these
issues. http://www.macromedia.com/shockwave/download/index.cgi?P1_Prod_Version=ShockwaveFlash

Credit:
Drew Copley

Greetings:
Fat code: presented by Yahoo and Weight Watchers. KROQ, and corn dog
manufacturers world-wide.

Copyright (c) 1998-2002 eEye Digital Security
Permission is hereby granted for the redistribution of this alert
electronically. It is not to be edited in any way without express
consent of eEye. If you wish to reprint the whole or any part of this
alert in any other medium excluding electronic medium, please e-mail
alert@eEye.com for permission.

Disclaimer
The information within this paper may change without notice. Use of this
information constitutes acceptance for use in an AS IS condition. There
are NO warranties with regard to this information. In no event shall the
author be liable for any damages whatsoever arising out of or in
connection with the use or spread of this information. Any use of this
information is at the user's own risk.

- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content.  The decision to use any or all of this information is
the responsibility of each user or organisation, and should be done so in
accordance with site policies and procedures.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the original authors to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:

	http://www.auscert.org.au/Information/advisories.html

If you believe that your system has been compromised, contact AusCERT or
your representative in FIRST (Forum of Incident Response and Security
Teams).

Internet Email: auscert@auscert.org.au
Facsimile:	(07) 3365 7031
Telephone:	(07) 3365 4417 (International: +61 7 3365 4417)
		AusCERT personnel answer during Queensland business hours
		which are GMT+10:00 (AEST).
		On call after hours for emergencies.

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: ftp://ftp.auscert.org.au/pub/auscert/AUSCERT_PGP.key

iQCVAwUBPNalUSh9+71yA2DNAQGh5wQAnSPUyV932dl3u+dMBlMtWsaDgB0TUyZO
XUOkvS2Z1e1/PlmYdZ+5FlEayz5IAmtjHsVUS1AOCzzF6AnrkiZ8vxTShr32u9Ty
v1YKNSW4UIV+t0FRxKq/ZzpU6ib9MefRZJf9Q0tNhflYB1cwBT6MQbFoLODEMLU0
Ne8i8yp5s7M=
=uXkO
-----END PGP SIGNATURE-----