Skip to main content
Rate:  

Kill Bit Action Process

Introduction

ActiveX controls are small programs, sometimes called add-ons, that are used on the Internet. These controls may be developed by Microsoft or by third-party software developers.


If a software vulnerability is discovered in an ActiveX control, the owner of that control—Microsoft or a third-party developer—should resolve the vulnerability and release a new version of the control. In addition, a kill bit can be issued which can prevent the older, vulnerable version of the control from executing within Internet Explorer.


This page describes the processes by which Microsoft will issue a kill bit for a vulnerability in an ActiveX control and, if the control is owned by a third-party developer, the steps that the developer must take to ensure a kill bit can be issued.


What is a kill bit?

A kill bit prevents an ActiveX control from executing. It is a registry entry for a particular Class Identifier (CLSID) that marks an ActiveX control as non-loadable in the browser and other scriptable environments, preventing the code from being executed.


If a third-party ActiveX control contains a software vulnerability, the owner of the control should address the vulnerability, update the CLSID for their control and release a new version of the control. At that point, the third-party may request that Microsoft issue a kill bit which prevents the older, vulnerable version of the control being executed.


We will not issue a kill bit for a third-party ActiveX control until the third-party has addressed the vulnerability. However, in the event of significant attacks against the vulnerability, we may make exceptions to these requirements and decide to issue a kill bit after coordinating with the vendor as outlined in our Coordinated Vulnerability Disclosure practices.


Read the following Security Research & Defense FAQs blog posts for more technical information about kill bits:

How are vulnerable ActiveX controls discovered?

Vulnerabilities in ActiveX controls may be discovered through a variety of means:

  • We may discover a vulnerable ActiveX control in the course of regular development or test work, or through research carried out via the Microsoft Vulnerability Research (MSVR) program
  • A vulnerable control may be reported to the Microsoft Security Response Center (MSRC) by the owner of a control, or by another third-party
  • A vulnerability may be the subject of a 0-day disclosure, when details of the vulnerability are made public before the control owner is able to address the vulnerability

When will Microsoft issue a kill bit?

If a software vulnerability exists in a Microsoft-owned ActiveX control, Microsoft will address the issue through well-established security update processes such as our security bulletins or security advisories. If the vulnerability exists in a third-party ActiveX control and has not been addressed by its owner, the Microsoft Vulnerability Research (MSVR) team coordinates with the owner of the control to help drive remediation.


Once the software vulnerability has been addressed, the third-party should revise the CLSID for their control and release an updated version of the control. At that point, if the owner requests that a kill bit be issued for their control, MSVR and MSRC manage that process and the kill bit is issued via the Microsoft security update release process.


Sometimes a vulnerability in a third-party control is reported or disclosed by a separate third-party. In these cases, MSVR will contact the owner of the control to confirm the issue and drive remediation work. During this process the control owner may request a kill bit for their control. MSVR will work closely with the owner of the control to help minimize disruption to users of the control.


Microsoft will not issue a kill bit for a third-party ActiveX control until the third-party has addressed the vulnerability. However, in the event of significant attacks against the vulnerability, Microsoft may make exceptions to these requirements and decide to issue a kill bit after coordinating with the vendor as outlined in Microsoft's Coordinated Vulnerability Disclosure practices.


Action steps for the third-party developer control owners

The following steps should be taken once a third-party becomes aware of a vulnerability in an ActiveX control that they own:

  • Develop a new version of the control that does not include the vulnerability
  • Revise the CLSID for the control
  • Request that a kill bit is issued for the old version of the control

If the third-party requests that Microsoft issue a kill bit on their behalf, Microsoft will require the following information from the control owner:


For each ActiveX control please provide the following:

  1. What is the public URL for your advisory on this vulnerable control?
  2. Is your company the original implementer of this control?
  3. What is the CLSID of the component you that requires a kill bit?
  4. Are there any older versions with other CLSIDs, if so what are those CLSIDs?
  5. Is this control intended to be instantiated in Internet Explorer?
  6. Does this control implement iobjectsafety?
  7. Is this control marked SFI or SFS?
  8. How widespread is this control? What product did it ship in?
  9. Is this component public?
  10. In your update will you revise the CLSID and set the kill bit (and AlternateCLSID) per http://support.microsoft.com/kb/240797?
  11. If there is a signed version of the control on the internet please provide the location.

To request that Microsoft issue a kill bit for a vulnerable ActiveX control, the above information should be sent to msvr@microsoft.com.

Read following Security Research & Defense FAQs blog posts for more information about kill bits and how Microsoft manages the process of creation and release.

Featured Download

Get inside information on how we manage vulnerabilities to help protect our customers.

MSRC Blogs

Microsoft Security :: Security Incidents | Investigating Security Issues | Engineering

BlueHat Archive

See past BlueHat Sessions

BlueHat v12

BlueHat v11

BlueHat v10

BlueHat v9

BlueHat v8