Protect yourself against future threats.
-----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-----