Controlling ActiveX in Internet Explorer

  • Article

In today’s post, I’ll provide a high-level overview of features in Internet Explorer that impact the loading of ActiveX controls.

Internet Explorer 6 and later allow the user to enable or disable ActiveX controls on an individual basis using the Manage Add-ons
screen.

Internet Explorer 7 introduced the
ActiveX Opt-In
feature. This feature showed the user a warning the first time that a given ActiveX control was loaded into the browser. This helps mitigate the threat that a given control may have incorrectly been marked “Safe-for-Scripting” even though it was never intended for use in the browser and exposes unsafe functionality. For instance, for a time, WinZip installed such an ActiveX control, and an IE6 user with a vulnerable control installed could be “zero-click” exploited just by browsing to a site.

A limited number of controls (~60) are exempted from ActiveX Opt-in because these controls (e.g. Adobe Flash, XMLHTTP, etc) are known to be designed for use by pages on the Internet. The list of controls that are exempt from this feature are called the PreApproved List
and their CLSIDs are listed in the registry under
HKLM\Software\Microsoft\Windows\CurrentVersion\Ext\PreApproved\
.

Internet Explorer 8 introduced the
Per-Site ActiveX
feature, which was added because we found that most ActiveX makers were not following the best practice to compile their controls using the ActiveX SiteLock template
. The Per-Site ActiveX feature shows the user a warning the first time that an ActiveX control is loaded into the browser from a site other than the website that installed the control. This is an attack surface reduction measure designed to help ensure that a control which was intended only for use on a single site (e.g. your computer maker’s System Update control) cannot be maliciously reused by a malicious site. Before the control is loaded on a new site, a prompt is shown:

Per-Site AX prompt
 

The list of sites a control has been approved to run on is maintained in the registry at

HKCU\Software\Microsoft\Windows\CurrentVersion\Ext\{CLSID
}\iexplore\AllowedDomains\

Pushing the Allow
button adds the domain of the current page to the AllowedDomains
key for the object’s CLSID. If the user chooses Allow for all websites
from the split button’s dropdown, *
is added to the AllowedDomains
key. The page refreshes when the user unblocks the control to ensure that any script that depends on the control is able to run correctly.

If the AllowedDomains
key for a control does not yet exist
and
the control was on the Pre-Approved List
, then a “Allow on all sites ( *
)” entry is automatically added to that control’s AllowedDomains key. That’s why, for instance, Adobe Flash is able to run on all sites without a Per-Site ActiveX prompt on each site.

The user may view the approval list for a control by clicking Tools
> Manage Add-ons
. In the Toolbars and Extensions
list, select the control, and click the More Information
link at the bottom of the screen.

Per-Site List UI

If you want
to see the Per-Site ActiveX prompt on each new site before loading a Pre-Approved Control, you can simply click the “Remove all sites” button in the Manage Add-ons UI. That will remove the “Allow on all sites (*)” entry, without
removing the AllowedDomains
key. That way, each new site you visit will prompt for permission to use the control.

Internet Explorer 9 introduces ActiveX Filtering
, a light-weight feature that allows you to browse the web without loading ActiveX controls. If the Tools
> ActiveX Filtering
option is enabled, when a site wishes to install or run an ActiveX control, it is automatically blocked, and the “filter” icon is displayed in the address bar:

AX Filter Icon

The URLACTION_ALLOW_ACTIVEX_FILTERING feature is enabled for the Internet, Trusted, and Restricted Sites zones, although it only has an effect if the user enables the feature using the menu.

When you use the filter icon to opt-out of ActiveX Filtering for the current site, the site’s domain is added to the registry key:

HKCU\Software\Microsoft\Internet Explorer\Safety\ActiveXFilterExceptions

If you subsequently re-enable filtering for the site using the filter icon, the exception is removed from the registry list.

There are a number of other ActiveX-related features, including:

  • IObjectSafety
    – An interface that allows an ActiveX control to indicate that it safe for scripting or initialization in untrusted (e.g. web) contexts
  • Killbits
    – A per-control flag that absolutely blocks a control from loading in the browser
  • Phoenix Bits
    – A mechanism for redirecting the load of a killbitted control to an AlternateCLSID
  • Repurpose Detection
    – A mechanism used detect if a given CLSID represents a proper ActiveX control. The mechanism checks to see whether the control properly implements IObjectSafety, IElementBehavior, or IElementBehaviorFactory, or belongs to an appropriate component category
    . If not (e.g. for a non-ActiveX COM object) the control is not made accessible to script and it is leaked to help prevent memory corruption during unload.

…but these latter features are controlled by the developer and generally are not visible to the user.

-Eric