• Internet Explorer is still the mostly used browser on the Internet (therefore a larger public can be impacted),
• Anyone can develop a new ActiveX Control to add new features to his web site,
• ActiveX developers are not fully aware of the security issues regarding this technology (a lot of ActiveX controls are poorly designed or implemented, from a security point of view).
• Once an ActiveX Control has been installed on a computer (when the user first visited a legitimate web site) it can be reused silently by any other web sites visited later.

The present article explores some aspects of the ActiveX technology and explains how to get rid of the harmful ones which could have been installed on a computer.

How to know which ActiveX Controls are installed on a computer?

Starting with Windows XP SP2, Internet Explorer has a new feature which allows to list  installed ActiveX Controls:

Internet Explorer > Tools > Manage Add-ons…

This list includes ActiveX Controls as well as other add-on modules which could have been installed on IE such as BHO (Browser Helper Objects), extensions, etc… In addition to the self explanatory "Show downloaded ActiveX controls" option, there is another option labelled "Add-ons that run without requiring permission". This option allows to list additional ActiveX Controls that have been installed on the computer but not downloaded by IE (ActiveX pre-installed by Windows or installed by third party products such as PDF Reader).

If you are not running Internet Explorer 7, or if you prefer to double check with another method, you can use the following steps:

• It is possible obtain the "downloaded ActiveX controls" list by looking at the content of the IE download folder. This folder is the one listed by the following registry key:
     HKLMSOFTWAREMicrosoftWindowsCurrentVersionInternet SettingsActiveX Cache
  Its default value is: "C:WindowsDownloaded Program Files".
  
  
• You can also use the NirSoft.net "ActiveXHelper" pieces of software which allows to list all the ActiveX controls installed on the computer by looking at the following Windows registry hive:
     HKEY_CLASSES_ROOTCLSID

The "ActiveXHelper" list is much more complete than the one produced by the IE "Manage Add-on" feature because:

• By default "ActiveXHelper" lists all "ActiveX" objects, even those which are not ActiveX Controls ("ActiveX" also designates COM and OLE objects). However,  it is possible to make it only list ActiveX Controls.
• Most of ActiveX Controls found on a Windows computer cannot be run through Internet Explorer. By default, Internet Explorer can only run an ActiveX Control which has been declared as "Safe for initialization" and "Safe for scripting" by its developer.

What does "Safe for initialization" (SFI) and "Safe for scripting" (SFS) mean?

The "SFI" and "SFS" flags are properties which are set by the ActiveX developer to state that the developed ActiveX control is harmless and may be safely initialized and run by a scripting language (and typically through Internet Explorer). However, there is no guarantee that the ActiveX control is indeed safe to have.

The "SFI" and "SFS" properties are first evaluated by Internet Explorer by querying the ActiveX (via the "IObjectSafety" methods). If this fails (case where the ActiveX does not implement "IObjectSafety" methods) Internet Explorer looks in the Windows Registry for "SFI" and "SFS" keys associated with that ActiveX.

In the "How to tell if ActiveX vulnerabilities are exploitable in Internet Explorer" article, Microsoft provides with a tool (source code) that can be used to retrieve the "SFI" and "SFS" properties for a given ActiveX Control. It is also possible to get such information through the Microsoft "OLE Viewer" tool (Oleview.exe) which is available in the Windows 2003 Resource Kit.

How to prevent a dangerous ActiveX Control from being run by Internet Explorer?

To deny the execution of a dangerous ActiveX Control on Internet Explorer, Microsoft provides with the so called security "kill-bit" feature. This feature was already covered in an article of the Cert-IST monthly bulletin in August 2003. In brief:

• Once a kill-bit has been set on an ActiveX Control, Internet Explorer will not allow it to be run any more. In the case where the ActiveX is not already installed, Internet Explorer will even refuse to download it because of the "kill-bit".
• The kill-bit is set by editing the Windows Registry (key "Compatibility Flags" in the "HKLM SOFTWAREMicrosoftInternet ExplorerActiveX Compatibility<CLSID_du_contrôle_ActiveX> " hive).

There is no Microsoft tool to easily set a kill-bit on a given ActiveX (except using the Windows Registry Editor). However NirSoft has released the  "ActiveX Compatibility Manager" free tool to do so.

Note:

• In the "ActiveX Compatibility Manager", be sure you did uncheck the "Display Only Installed Component" option, otherwise it will hide most of the ActiveX Controls listed in the "HKLMSOFTWAREMicrosoftInternet ExplorerActiveX Compatibility" registry key.
• The "Manage Add-ons…" feature of IE has a button to enable or disable a listed ActiveX Control. Although the result is equivalent to a "kill-bit", this feature does not rely on the "kill-bit" mechanism (see the "The Kill-Bit FAQ: Part 2 of 3" Microsoft article).

Microsoft often uses "kill-bits" to disable any vulnerable ActiveX Controls. Microsoft Security bulletins are often dedicated to dangerous ActiveX Controls deactivation with "kill-bit":

• MS08-023 (April 2008): Security Update of ActiveX Kill Bits (948881)
• MS08-032 (June 2008): Cumulative Security Update of ActiveX Kill Bits (950760)

It is worth noting that these Microsoft security bulletins also cover third-party ActiveX Controls. In fact any editor may ask Microsoft to include in future security updates a kill-bit for their own ActiveX Control. The benefit for the editor is the usage of the "Windows Update" technology which guarantees a rapid deployment of the "kill-bit" in the Windows community.

The following question could be raised:

Should I apply a kill-bit patch if I never used the ActiveX before?

Yes, it is important to set a kill-bit on any known to be vulnerable ActiveXControls, even if the user does not plan to use this ActiveX Control.

If one does not do that, one is vulnerable to the following attack. An attacker who has a copy of a vulnerable ActiveX (e.g. he downloaded a copy of the ActiveX Control from the official distribution site prior to the disclosure of the vulnerability) can craft a malicious web page which uses the vulnerable ActiveX Control and force the visitor to download it from the malicious web site (via "CODEBASE" tag). In that case anyone who did not set the "kill-bit" for this ActiveX Control will:

• first download the vulnerable ActiveX,
• which will then be used by the attacker to perform harmful actions on the visitor's computer.

The Symantec security blog reported in June 2008 in the "ActiveX Vulnerabilities: Even When You Aren't Vulnerable, You May Be Vulnerable" post that such an attack scenario was used to exploit a vulnerability in the vulnerable "Access Snapshot Viewer" ActiveX Control from Microsoft (CERT-IST/AV-2008.305 advisory). In such a case, the vulnerable ActiveX Control was digitally signed by Microsoft which allowed the vulnerable ActiveX Control to be silently installed on any Windows system on which the user trust Microsoft certificates. This makes this attack even more frightening.

What is the "phoenix bit"?

The last concept we would like to talk about is known as "Phoenix bit" (a.k.a. "Alternate CLSID").

We didn't mention it yet but each ActiveX has a "CLSID" (Class Identifier) which is a unique number assigned to that Control ActiveX (e.g. "F0E42D50-368C-11D0-AD81-00A0C90DC8D9" is the CLSID for the "Access Snapshot Viewer" Microsoft ActiveX). The CLSID is used to unambiguously refer to an ActiveX. It is used:

• in a web page which uses an ActiveX Control,
• in the Windows registry to assign a property (such as a "kill-bit") on an ActiveX Control.

Once a "kill-bit" has been set on an ActiveX Control, it is not possible to publish a new version, which fixes the vulnerability, using the same CLSID (because the "kill-bit" will prevent the new version of the ActiveX to run). It is then necessary to assign a new CLSID for that new version of the ActiveX.

To allow the web page that still use the old (vulnerable) CLSID to work, Microsoft introduced the concept of "Phoenix bit". The "Phoenix bit" is set on the old CLSID. It indicates that a new CLSID must be used instead of the old CLSID. The "Phoenix bit" is set in the Windows Registry, in an"AlternateCLSID" key located at the same place as the "kill-bit" key.

Conclusion

ActiveX is a powerful technology which enables web developer to add unlimited features to Internet Explorer. This has also the severe drawback to be one of the major security weaknesses of Internet Explorer. The "on-the-fly installation" concept that surrounds that technology is definitely dangerous. Besides this feature is now  disabled by default in Internet Explorer 7: the first time a new ActiveX is required, it is blocked by IE7 and the user must explicitly unlock it (IE7 "opt-in" feature).

By exploring some of the internals of ActiveX Controls, this article shows that ActiveX Controls are complex objects which might be difficult mastering. The fact that Microsoft released a series of three technical articles called "kill-bit FAQ" (on the "Security Vulnerability Research & Defense" blog) confirms that this subject is not trivial.

For more information

• Microsoft "kill-bit FAQ" series:
  http://blogs.technet.com/swi/search.aspx?q=%22kill-bit+FAQ%22
  
  
• Security of ActiveX Control (dated 2001):
  http://oreilly.com/catalog/malmobcode/chapter/ch11.html
  
  
• Tutorial from "Infini Software" about ActiveX (in French):
  http://www.infini-software.com/Encyclopedie/Developpement/VisualStudio6/VisualBasic/French/ActiveXInstallation/Index.wp