It is very common for Microsoft security bulletins to include “Kill-Bits” to disable individual ActiveX controls / COM objects. Here is the second part of our three-part Kill-Bit FAQ.
The Kill-Bit FAQ – Part 2 of 3
How do ActiveX Controls, OLE Controls, and COM Objects relate?
An ActiveX control is an OLE control that is intended to be used inside a web browser. Likely an ActiveX control is marked Safe for Scripting and Safe for Initialization as well as being packaged to be installed via Authenticode. More information on the difference between OLE and ActiveX controls is available here.
All ActiveX / OLE controls are COM objects, but not vice versa. ActiveX / OLE controls are built on COM and implement a required minimum set of interfaces in order to operate properly within any OLE container. More information on the requirements that a COM object must meet in order to be considered a valid OLE control can be found here.
ActiveX Controls, OLE Controls, and COM Objects all can be instantiated in IE with an OBJECT tag or through script (“new ActiveXObject”, etc.) All are subject to Safe for Scripting, Safe for Initialization and the Kill-Bit.
Will IE host any ActiveX Control, OLE Control, or COM Object?
Sort of. Prior to MS05-052, IE treated all COM objects equally. Any registered COM object could be instantiated within the browser just as long as the Kill-Bit wasn’t in place for its CLSID. Safe for Scripting and Safe for Initialization would be verified only after instantiation as particular operations were attempted on the object. Think about it – there’s no way to call into a control’s implementation of IObjectSafety without actually instantiating the control!
In MS05-052, IE made a change that affects the way controls are instantiated in the Internet zone. The IObjectSafety check is now frontloaded so that IE can determine control safety status quickly and abort instantiation as soon as a control is identified as unsafe. Extra unnecessary probing of COM objects upon instantiation was a contributing factor to the exploitability of many COM object instantiation bugs. Control authors can set the compatibility flag value of 0x00800000 on their controls to opt-out of this new behavior if necessary.
How does the Kill-Bit interact with “Safe for Scripting” and “Safe for Initialization” (SFS / SFI)?
The Kill-Bit trumps SFS / SFI. If a control has the Kill-Bit, it just won’t load within Kill-Bit aware applications, period.
If I Kill-Bit my vulnerable object / control, should I still release a fixed version?
If you are releasing a Kill-Bit for a vulnerable object, it makes sense to issue a code fix as well. A code fix will mitigate the threat posed by environments that provide an attack scenario through which the vulnerability can be exploited yet do not support the Kill-Bit. If you do release a fixed version as well as a Kill-Bit, make sure to give the control a new CLSID and issue a “Phoenix-Bit” (see below) as necessary if the update control must operate within Kill-Bit aware environments.
What is the “Phoenix-Bit” a.k.a. AlternateCLSID?
Since a Kill-Bit completely prevents a control from loading in the browser, there needs to be a way to safely revise a control without breaking web content that references the killed CLSID. The Phoenix-Bit does this – it allows control developers to kill the vulnerable CLSID and transparently redirect requests for the old CLSID to a new CLSID. The name “Phoenix-Bit” honors the mythical Phoenix bird known for its regenerative ability.
When verifying that a CLSID has or has not been killed, MSHTML will check to see whether an alternate CLSID has been provided for use in place of a killed CLSID. This will allow pages or Kill-Bit aware applications that have not been revised to refer to the new CLSID and still function.
To implement the Phoenix-Bit, add an “AlternateCLSID” string value to the killed CLSID under the ActiveX Compatibility key. The Phoenix-Bit requires that the Kill-Bit is also set. Example:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\
{CLSID of killed ActiveX control}, Compatibility Flags, 0x0400
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\
{CLSID of killed ActiveX control}, AlternateCLSID, “{CLSID of alternate ActiveX control}”
Warning - Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Modify the registry at your own risk.
The alternate CLSID requires the curly braces. It is possible to chain redirects up to ten levels deep.
The Phoenix-Bit was introduced in IE6 SP1 and was backported to downlevel versions (5.01 and 5.5) in 2003. It is supported on all fully patched versions of IE >= 5.01.
If I implement the Phoenix-Bit should the control still support the old CLSID?
If the control is intended to be hosted outside of IE, then yes. In that case the control should support both the old CLSID and the new CLSID. Otherwise, hosts that do not understand or honor the Phoenix-Bit will be broken if they reference the control by the old CLSID.
Are there any alternatives to the Phoenix-Bit?
Ditching your control’s existing CLSID may be difficult if the CLSID is hard-coded in many web pages. The recommended solution to this problem is the Phoenix-Bit (see above). Besides the Phoenix-Bit, there are a few potential alternate solutions you may want to investigate:
Is there an easy way for users to block ActiveX controls in Internet Explorer without setting a Kill-Bit?
Yes, the Add-on Manager in XP SP2 and above allows users to easily disable specific ActiveX controls in Internet Explorer. It’s worth mentioning though that this is not technically equivalent to setting a Kill-Bit. So for example, Windows applications that respect the Kill-Bit to block ActiveX controls may or may not respect the Add-on Manager settings.
- Security Vulnerability Research & Defense Bloggers
*Postings are provided "AS IS" with no warranties, and confers no rights.*
