For years, many security consultants and well-meaning guidelines have recommended completely disabling ActiveX in Internet browsers (mainly Internet Explorer) to prevent a particular type of Web client-side attack. Running a browser without ActiveX enabled can be a frustrating experience for end-users, as many popular and legitimate Web sites use ActiveX to enhance the user's overall experience.

Barely a week goes by without one or more ActiveX controls from various vendors being declared unsafe, so I can understand the caution. You should always disable unneeded and unauthorized software, but running a browser without ActiveX enabled when other more reasonable alternatives exist is throwing the baby out with the bathwater.

(Disclosure: Although I work full time for Microsoft, everything I say here could equally apply to Sun's Java.)

Yes, hundreds of ActiveX controls have been found, over the last decade, to contain buffer overflows or to allow malicious behavior. But with a few exceptions, the problem isn't with the ActiveX platform itself, but with insecure program code passed along using ActiveX mechanisms. Sometimes the ActiveX controls are downloaded by users, but problematic controls are just as likely to be preinstalled by hardware and software vendors.

ActiveX is a platform, not a language. No one codes in the ActiveX language. ActiveX is a popular way for a software vendor to transport its program (normally in .CAB, .DLL, or .OCX file formats) from a Web site, then install and launch it in a user's browser session in an almost seamless manner.

There are many other methods to download and install Internet-based code, but ActiveX is fairly easy to use, integrates well with multiple Internet browsers, and contains many native security mechanisms. For one, vendors can sign their ActiveX controls with a publicly trusted digital certificate to confirm to the end-user that the program they are receiving is indeed from the purported vendor. There have been a few malicious uses of digital certificates over the last decade, but the inappropriately used certificates are quickly revoked when discovered. Overall, the publisher identity system works pretty well in identifying the originating software publisher, when users pay attention to it.

But unfortunately, a digital signature doesn't guarantee that the control won't do something unauthorized to the user's system or that it doesn't contain an exploitable vulnerability. No programming language or Internet transportation method can do that. ActiveX gives vendors one way to transport their program from source to destination, but it doesn't absolve the vendor of using SDL (secure design lifecycle) programming.

Now, it is completely valid to ask if ActiveX's ability to seamlessly download and integrate programs within the context of a browser is a safe thing in today's scary Internet world. But if you're going to identify an Internet programming mechanism involved with more Internet crime than another other mechanisms, you would single out JavaScript. JavaScript is involved in nearly 100 percent of browser-related, client-side attacks, including the ones involving ActiveX, and you don't hear popular calls to get rid of JavaScript.

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.

Some people, rightly or wrongly, simply hate ActiveX. They've been burned before or are tired of reading stories of vendors who continue to use insecure programming methods. I can understand that, but disabling ActiveX when you can prevent the unsafe controls from loading seems a little heavy-handed. Is JavaScript next? Should ASP, SQL, or PHP be disallowed on the server just because a programmer writes insecure programs using them?

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?

Posted by Roger Grimes on April 11, 2008 03:00 AM