It is very common for Microsoft security bulletins to include “Kill-Bits” to disable individual ActiveX controls / COM objects. Here is the first part of a three-part FAQ we have developed to answer some questions around the Kill-Bit and related functionality.
The Kill-Bit FAQ – Part 1 of 3
What is the Kill-Bit?
The Kill-Bit (a.k.a. “killbit”) is not actually a bit. The Kill-Bit is a registry entry for a particular CLSID that marks the COM object / ActiveX control referenced by that CLSID as non-loadable in the browser and other scriptable environments. Microsoft releases Kill-Bits in security updates to block vulnerable ActiveX controls and COM objects which are vulnerable to security flaws when hosted in the browser.
Issuing a Kill-Bit for the control marks that particular control as forbidden to instantiate in the browser. Issue a Kill-Bit by setting the Compatibility Flags value to 0x400 for a control in the registry as described in KB Article 240797.
Where are Kill-Bits in the registry?
Kill-bits are located in the registry:
x86 IE / x86 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control
x64 IE / x64 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control
x86 IE / x64 OS: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\CLSID of the ActiveX control
(3/11/2009 Update: added detail on x86 / x64 scenarios)
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.
Note that not all CLSIDs listed in this location are killed, only controls containing 0x400 in the Compatibility Flags DWORD value. The acceptable values for Compatibility Flags are documented here.
If you are setting a Kill-Bit, you may want to ensure that you don’t wipe out any existing Compatibility Flags set for the CLSID being killed. If you are removing a CLSID, to preserve any pre-existing Compatibility Flags, subtract 0x400 from the Compatibility Flags DWORD value and only remove the CLSID key if the Compatibility Flags value was set to 0x400 exactly.
What applications respect the Kill-Bit?
The Kill-Bit is respected in Internet Explorer (all zones) and also in Microsoft Office scenarios where objects are embedded within documents. The Kill-Bit should also be effective by default in any other application or platform that hosts the IE browser’s rendering engine (MSHTML). A notable exception are HTAs – with an HTA it is already possible to load unsafe controls and run arbitrary code. HTAs are an unsafe file type.
(3/11/2009 Update: HTAs do currently respect the Kill-Bit for objects instantiated via the OBJECT tag. The Kill-Bit is not respected when HTAs instantiate objects in script. Thanks to Nicolas Noakes for reporting this. The Kill-Bit behavior within HTAs may change in the future to become more consistent.)
A control could conceivably have a flaw so severe that a Kill-Bit does not effectively block all attack vectors. For example, imagine a control that is found to implement a web server which suffers from a buffer overrun in the code responsible for parsing web requests. In this case, a code fix must be issued – simply implementing a Kill-Bit will not provide a comprehensive solution because any application which uses the control is exposed to the vulnerability.
If an application or platform hosts controls and allows those controls to effectively be driven by untrusted data, that environment should respect Safe for Scripting, Safe for Initialization and Kill-Bit logic. Otherwise, the environment should provide some other equivalently or more restrictive policy, such as an allow-list of known-good scriptable objects.
Why does my vulnerable control / object need a Kill-Bit?
Kill-Bits must be issued to prevent old / vulnerable signed versions of controls from being effectively foisted on users. Even if a user has a fixed version of the control on their system, a renamed / signed DLL or OCX served from a malicious web page could revert their machine to an insecure state.
Additionally, the “Always trust content from…” checkbox on the Authenticode dialog box, if checked for a particular trusted publisher, could allow old / vulnerable signed versions of controls to install silently. Otherwise, the victim of such an attack would be presented with an Authenticode dialog from a presumably trustworthy publisher. Once the old / vulnerable control is installed, the attacker can immediately script to it.
Kill-Bits are effective regardless of their origin but obviously wider distribution of a Kill-Bit ensures more comprehensive protection. If you would like Microsoft to distribute a Kill-Bit in Windows on your behalf, contact the MSRC and include details on the CLSID(s) in question.
What is the relationship between an OBJECT tag’s CLSID and CODEBASE attributes?
It is possible to specify any CLSID paired with any CODEBASE in an OBJECT tag. If that CLSID isn’t already registered, IE will attempt to download the control specified in the CODEBASE attribute of the OBJECT tag. It isn’t feasible for IE to know what control a package installs before that package is actually installed.
Will controls with the Kill-Bit still load in other applications?
Yes. See “What applications respect the Kill-Bit?” above.
Is it still possible to download and install an ActiveX control with the Kill-Bit?
Yes. Setting the Kill-Bit on a control only affects that control’s ability to instantiate within Kill-Bit aware hosts such as IE.
- Security Vulnerability Research & Defense Bloggers
*Postings are provided "AS IS" with no warranties, and confers no rights.*
Updates March 11, 2009 - updated blog post and flagged where updates were made.
