Braindump: Feature Control Keys and URLActions

  • Article

Note: The “brain dump” series is akin to what the support.microsoft.com team calls “Fast Publish” articles—namely, things that are published quickly, without the usual level of polish, triple-checking, etc. I expect that these posts will contain errors, but I also expect them to be mostly correct. I’m writing these up this way now because they’ve been in my “Important things to write about” queue for ~5 years. Alas, these topics are so broad and intricate that a proper treatment would take far more time than I have available at the moment.

I’m frankly amazed that I’ve made it to the end of an eight-year run on the IE team without having written a general blog about Feature Control Keys and URLActions. It’s time to rectify that oversight, with one day left on the clock before I move along. Both of these topics are covered at length on MSDN, but some of the philosophy behind how they came to be is lacking in the formal documentation.

Feature Control Keys

Feature Control Keys were formally introduced in the huge Windows XP Service Pack 2 update to Internet Explorer 6. XPSP2 massively tightened security for Internet Explorer, but the team faced a big problem—thousands of applications host the Web Browser Control and if the Internet Explorer lockdowns were applied to those applications, they could break, leading users to avoid installing XPSP2 and thus impeding the value of the security push entirely. On the other hand, if the team simply exempted all non-IE applications from the lockdowns, those other applications could be vulnerable to the same attacks forbidden in Internet Explorer, allowing attackers a means to compromise the system by going around Internet Explorer’s defenses into an unhardened Web Browser Control host (e.g. Windows Media Player, for one). In some cases, applications would want exactly the same protections as IE (e.g. 3rd party browsers built on the Web Browser Control, which included at that time Maxthon and Avant Browser). On the other hand, some applications would want none of the protections (e.g. Microsoft Money hosted the Web Browser Control, but only loaded fully-trusted content into it).

Thus were born Feature Controls, a mechanism which allowed an application to opt-in or out to individual security defenses (and later compatibility modes) on a per-process basis. Feature Controls could be set in one of two ways: by manipulating keys in the registry, or by calling the CoInternetSetFeatureEnabled API within the running process. Only a limited number of Feature Controls (often abbreviated FCK for Feature Control Key) can be set via the API for two reasons: First, because some settings must be determined at process startup, before the caller could have called the API, and Second, because the API has generally not been updated to support the many dozens of FCKs introduced after the launch of XPSP2. As a consequence, in almost all cases, FCKs are set via the registry.

You can see the complete list of public Feature Control Keys on MSDN. This list explains how to set the FCK for your process’ name, as well as listing what each FCK does and what its default is. Note: Internet Explorer internally may use some other FCKs that are not documented, but these are not a part of the public API, and can be subject to change in any monthly update.

One significant shortcoming of the registry-based Feature Control Key system is that process names must be distinctive if you hope to apply different FCK settings across versions of the program. For instance, all versions of Microsoft Word are named WinWord.exe, which means that if you have side-by-side versions of Office 2010 and Office 15, the FCKs set for the last-installed version will overwrite whatever FCKs were applied to the previous version. This long-standing limitation is a bit of a hassle, but in practice not a big enough problem to warrant a change since 2003.

Feature Control Keys are sometimes criticized for sometimes prioritizing compatibility over security for 3rd party applications; this seems non-intuitive to some. The apt metaphor I like to use is: “Sports cars go fast because of their brakes.” If sports cars didn’t have excellent brakes to complement their engines, drivers would be unable and unwilling to push them to their performance limits, because the inability to control the speed would be fatal. Similarly, if Internet Explorer adopted a “All security features must be enabled in all contexts at all times” stance, users would quickly stop installing patches in order to prevent the compatibility fallout of such a stance. As a result, enhanced security features would bizarrely result in users becoming less secure.

URLActions

Feature Control keys are applied on a per-process basis, which isn’t sufficiently granular for many needs. Some privileges (e.g. the ability to download ActiveX controls or spawn popup windows) can be safe in a trusted context (e.g. an Intranet site) and unsafe in an untrusted context (Internet pages).

Internet Explorer’s Zone-based security architecture is comprised of two parts:

  1. A set of rules that map content into one of the five security zones, and
  2. A set of security policy settings for each zone that control the privileges (called URLActions) granted to that Zone.

There are nearly 100 URLActions in the browser today, and a half dozen or more are added in each new version. Most of them can be viewed by opening Internet Explorer and clicking Tools > Internet Options > Security, picking a Zone, and clicking the Custom Level… button. However, some “headless” URLActions are not displayed in the UI and can only be controlled programmatically or via the registry.

Internet Explorer (and other programs) determine what privileges should be granted to content by calling the ProcessURLAction API on the IInternetSecurityManager for the process. Applications hosting a Web Browser Control can supply their own security manager for the control to use (using the IServiceProvider’s ProfferService API) but most simply rely on the default security manager. The default security manager gets its settings from four registry nodes: the HKLM and HKCU nodes under \SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones, and the associated policy keys.

Aaron Margosis’ excellent Zone Analyzer tool allows you to view your default URLAction settings, including determining the “effective” settings which result from the precedence rules for the four registry nodes.

Working Together

The URLAction architecture predates Feature Control keys, but some security features are controlled using both mechanisms.

For instance, FEATURE_ZONE_ELEVATION controls whether a given process is opted into Zone Elevation Restrictions. If and only if a process has these restrictions enabled does a cross-Zone navigation then consult the target site’s URLACTION_FEATURE_ZONE_ELEVATION setting to determine whether the cross-Zone navigation should be permitted. If the FCK is Disabled, or if it is Enabled and the target zone’s URLAction is Allow, then the navigation is permitted.

 

This was just a quick summary of these two important subsystems, but I hope you find it useful anyway!

 

-Eric Lawrence