In all but the most secure enterprise environments, a more moderate support statement would be to approve needed ActiveX controls, while not allowing users to install uninspected and unapproved controls and programs.
Many programs allow administrators (or end-users) to control what software may run on their computer, including many mechanisms built into Windows. For one, only administrators can download and install new ActiveX controls. As long as most of your end-users aren't running as administrators, this gives the administrator a lot more control. Many environments incorporate approved ActiveX controls into their deployment and build methodologies. And since the end-user isn't an administrator (hopefully), they can't install new controls.
If end-users are administrators and can install their own controls, there are still several defenses against unapproved controls. The primary method is to dictate what types of controls (and other active content, such as binary behaviors and .Net components) can be downloaded and installed in the browser. Internet Explorer allows dozens of settings, regarding signed and unsigned controls to be governed across various Web site zones (such as Internet, Restricted, Intranet, and so on)
If a particular control is known to be malicious, end-users or administrators can set a "kill bit." This basically involves finding the control's related CLSID identifier in the registry and configuring a value to be 0 (disabled) versus 1 (enabled). Jesper Johansson has a couple of great articles on setting kill bits, including how to automatic the process using scripts and Active Directory. Programs can also be allowed or disabled using various group policies and knowing the program's unique CLSID.
Windows 2000 and above domain computers can also use Software Restriction Policies (SRP), which can restrict (or allow) programs based on name, location, digital certificate, or Internet zone. Windows Vista has the added benefit of the new ActiveX Installer Service (AXIS). It allows an administrator to download approved ActiveX controls to pretrusted locations, and when a user needs the control, Windows will redirect the user's browser to the trusted location first. Controls in the trusted location (and you can define multiple locations) can be silently installed, prompt the user for installation, or be prohibited. Controls not located in the trusted locations fall back to the normal ActiveX install rules, and can be controlled using one of the previously stated methods. You can see much more detail in this white paper on AXIS.
In preparation for this blog column, I searched the Internet for vulnerable ActiveX controls. What I found is that most ActiveX control vendors have fixed the holes in their products in a relatively speedy manner. And nearly all vendors that were reported as having a vulnerable ActiveX control have not been found to have them at a later date (although I did locate three instances that contradicted this finding). Further, I discovered that the vast majority of the superpopular programs (which nearly everyone has installed) and which are getting patched and repatched every month, aren't using ActiveX. What do we do now?