Setting the Kill Bit on ActiveX Controls

Q: Every month, Microsoft security vulnerabilities are discovered in ActiveX controls in Microsoft Internet Explorer (IE). It seems like there should be a strategic way to deal with these vulnerabilities rather than deploying patches, especially for organizations like mine that resist installing updates that could threaten stability. Why doesn’t Microsoft do something about these vulnerabilities? What measures do you suggest our organization take?

A: You're right, the current situation seems crazy. Every month, Microsoft releases security patches that correct some buffer overflow in an ActiveX control and set the kill bit on the control to prevent IE from loading it. You'd think that Microsoft could just set the kill bit in all ActiveX controls that the company doesn't think should be loaded in IE in the first place.

Microsoft claims to have solved this problem in IE 7.0 by disabling all ActiveX controls by default. You can approve a control for loading by clicking the little yellow bar that appears under the toolbar when a page tries to load a control. However, the problem isn’t really solved because all the user has to do is let the control be loaded. How many users can determine whether a given control should be loaded by a Web page? Most users will let the control be loaded without a second thought.

To escape the constant patching of ActiveX vulnerabilities, I suggest setting the kill bit on a control as soon as Microsoft issues a security bulletin about that control and then taking your time to test and deploy the patch. Setting the kill bit manually is a simple registry tweak (240797), but the manual approach isn't practical if you have multiple workstations to secure.

In this situation, Group Policy Administrative Templates come to the rescue. Administrative Templates are simple ADM files that you can write to push out registry tweaks to thousands of computers automatically by using Group Policy. Figure 1 shows an Administrative Template for setting the kill bit on the Windows Management Instrumentation (WMI) Object Broker control, whose vulnerability is documented in the Microsoft article "Microsoft Security Advisory: Vulnerability in Visual Studio 2005 could allow remote code execution" at http://support.microsoft.com/kb/927709. You can probably see from Figure 1 that enabling the policy sets the Compatibility Flags registry value under the HKEY_LOCAL_MACHINESOFTWAREMicrosoftInternet ExplorerActiveX Compatibility\{7F5B7F63-F06F-4331-8A26-339E03C0AE3D} registry subkey to 0x00000400. 7F5B7F63-F06F-4331-8A26-339E03C0AE3D is the globally unique identifier (GUID) of the WMI Object Broker control; 0x00000400 is the special value that kills the control.

To kill the WMI Object Broker control, load this ADM file into a Group Policy Object (GPO) and you're ready to set the kill bit on as many computers as you need. Once the GPO is configured and replicated to all domain controllers (DCs), it typically takes fewer than 90 minutes to hit all the computers affected by the GPO.

To kill another ActiveX control, copy the ADM file's text between and including POLICY and END POLICY and paste it in the same ADM file below the original policy. In the new policy that you're creating, change 927709 - WMI Object Broker to something descriptive for the additional control to be killed. Then replace 7F5B7F63-F06F-4331-8A26-339E03C0AE3D with the GUID of the control to be killed as specified in the security bulletin or advisory in question. You can add as many policies for as many controls as you like to the ADM file.

To load this ADM file into a GPO, in Group Policy Editor (GPE), right-click Computer ConfigurationAdministrative Templates under the desired GPO, and select Add/Remove Templates. In the Add/Remove Templates dialog box, click Add. Browse to your ADM file and click Open, then Close. Now you should see a new folder called KillBits under Administrative Templates. Select the KillBits folder, and you'll see an entry for each control for which you've created a policy in the ADM file. Just enable the GPO for each control, and computers that apply this GPO will begin killing the specified classes as the computers refresh Group Policy or reboot.

Some antivirus vendors diligently add detection of ActiveX vulnerabilities, so these file-based exploits are yet another reason to keep your antivirus signatures up-to-date.