Advisories
Macromedia Flash Activex Buffer overflow
Release Date:
May 2, 2002
Severity:
High (Remote code execution)
Vendor:
Macromedia
Systems Affected:
Systems with Flash Activex OCX Version 6, revision 23
(Possibly older versions)
This includes most installations of Windows.
Overview:
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.
Technical Details:
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 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 mandatory.
Risk should be mitigated to a satisfactory level when users upgrade to the new OCS.
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-2009 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 email 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, implied or express, with regard to this information. In no event shall the author be liable for any direct or indirect 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.
May 2, 2002
Severity:
High (Remote code execution)
Vendor:
Macromedia
Systems Affected:
Systems with Flash Activex OCX Version 6, revision 23
(Possibly older versions)
This includes most installations of Windows.
Overview:
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.
Technical Details:
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 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 mandatory.
Risk should be mitigated to a satisfactory level when users upgrade to the new OCS.
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-2009 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 email 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, implied or express, with regard to this information. In no event shall the author be liable for any direct or indirect 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.
