The Kill-Bit (or "killbit") is a Microsoft Windows registry value that prevents an ActiveX control from being used by Internet Explorer. More information is available in Microsoft KB article 240797. If a vulnerability is discovered in an ActiveX control or COM object, a common mitigation is to set the killbit for the control, which will cause Internet Explorer to block use of the control. Or will it?

Killbits are a good thing. They are part of the mechanism for mitigating ActiveX vulnerabilities. Other technologies, such as signed java applets, may not have this sort of capability. And in some cases, such as when the vendor is no longer in business, the killbit may be the best mitigation for the vulnerability. However, it is not infallible.

I first encountered a killbit weakness four years ago. I discovered a way to completely bypass the killbit protection on Microsoft Windows systems--just by making a trivial modification to the HTML source code. The impact of this vulnerability is that an attacker would have the entire arsenal of known-vulnerable ActiveX controls at his disposal, which is pretty significant. More information is available as US-CERT Vulnerability Note VU#998297. Fortunately, we have not seen any indication of attackers using the technique in the wild.

Fast forward to 2009. Mark Dowd, Ryan Smith, and David Dewey presented great information at Black Hat about subverting ActiveX controls. One of the impacts is a limited way of bypassing the killbit. Further details are available in the paper Attacking Interoperability [pdf]. This vulnerability is addressed in Microsoft Security Bulletin MS09-034, so make sure you're up to date.

Today, in the process of testing some Dranzer functionality on x64 versions of Windows, I noticed some odd behavior with respect to killbits. In particular, the killbit was not being obeyed. Déjà vu perhaps? Actually, not in this case. Although the behavior is documented (as of March 11, 2009), it may not be very well understood.

The default version of Internet Explorer on 64-bit versions of Microsoft Windows is actually the 32-bit version of the browser. This is to retain compatibility with existing ActiveX controls, such as Adobe Flash, Sun Java, or Microsoft Update. When running this browser configuration, the 32-bit Internet Explorer on x64 platforms obtains the killbit values from a different registry location. In particular, 32-bit IE on 32-bit Windows and 64-bit IE on 64-bit Windows both look in the following location:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\ActiveX Compatibility\

However, 32-bit IE on 64-bit Windows will look here:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\ActiveX Compatibility\

What this means is that killbits that have been set manually may fail to set the Wow6432Node version of the registry key. In fact, even Microsoft fails to mention the Wow6432Node location for killbits on x64 platforms in KB Article 240797.

Software vendors and end users who are relying on the killbit for protection against ActiveX vulnerabilities need to be using both registry locations. Otherwise, Windows x64 users will remain at risk.