Enabling “Initialize and script ActiveX controls not marked as safe” in ANY zone can get you hurt, bad.

This post is about a security setting that is often underestimated in its ability to enable serious harm when relaxed.  Microsoft’s security guidance, the US Government Configuration Baseline (USGCB) and other security guidance currently mandate only that it be locked down in the Internet and Restricted Sites zones, which are of course the highest risk zones.  But relaxing this setting in the Local Intranet or Trusted Sites zones can turn those zones into very high risk places to browse, and this is exactly what I often see being done in enterprise environments.  The risk is real that anyone who has any control over any content on any web server in those zones could easily and surreptitiously take complete control of visitors’ computers and user accounts, and in a way that could be difficult to trace.

In this post, I’ll describe what the setting means and why it has sometimes been set to an insecure state.  I will vividly demonstrate the potential harm, and describe some ways to check whether the setting is enabled in your environment.  In a follow-up post I will describe some ways to update web apps so that they can continue to work with the setting in its default, secure state.

What is “Initialize and script ActiveX controls not marked as safe for scripting”?

In the early days of the World Wide Web, the functionality provided by HTML was very limited. ActiveX provided a means by which the richer UI and capabilities of Windows desktop applications could be incorporated into web pages.

ActiveX is a software re-use technology built on Microsoft’s “Component Object Model” (COM).  For example, ActiveX allows a Word document to embed an Excel spreadsheet and for Excel to expose parts of its user interface through Word when Word opens the outer document.  ActiveX allows any program to incorporate Word’s spell-checker if it is installed.  ActiveX enables “scriptable” interfaces through which the full capabilities of binary components can be exposed to scripting languages such as VBScript and JScript (this is also known as “OLE automation” or simply “Automation”).  And most importantly here, ActiveX is Internet Explorer’s “plug-in” model, allowing IE to load and use custom binary components from within web pages.  Those web pages often interact with ActiveX components through scripting interfaces.

Because ActiveX is a general-purpose code re-use technology and is not designed solely for web page use, not all ActiveX components are appropriate to use from within web pages.  There are limits to what a web site you visit should be able to do on your computer through your browser.  For example, a web site that you visit should not be able to run arbitrary programs on your computer without your consent.  This and other guidelines for evaluating whether an ActiveX is safe for use on a web page are described in Designing Secure ActiveX Controls.

An ActiveX component is assumed not to be safe for use within a web page unless it asserts its safety through one of several available mechanisms (described here*).  The component must assert that it is both safe for initialization and safe for scripting.  “Safe for initialization” basically means that the component won’t violate the user’s security even if initialized with untrusted or malicious data.  “Safe for scripting” means that its scripting interfaces can’t be abused by maliciously-intended script to cause harm to the user.

By default, Internet Explorer will refuse to load an ActiveX component that is not asserted to be safe for scripting and initialization when referenced by a web page hosted on a remote computer; that is, from a site in any IE security zone other than the Local Machine zone.  This can be controlled through a security setting, “Initialize and script ActiveX controls not marked as safe for scripting.”  This setting can be defined separately for each security zone through user settings or mandated through Group Policy.  Beginning in IE7, it is set by default to “Disable” for all zones (except the Local Machine zone in which it is set to “Prompt”).

Microsoft Word provides a good example of an ActiveX component that is not intended to be used from a web page.  While Word’s automation interfaces have many legitimate uses in Office and other desktop applications (e.g., using Visual Basic for Applications (VBA)), those interfaces include the ability to create and delete files, and instantiate and invoke other ActiveX components.  Ultimately, its scripting interfaces allow it to be used to perform almost any action that the user is allowed to perform.  The Windows Script Host interfaces are an even more powerful example of unsafe ActiveX components.  They provide scriptable interfaces to perform registry and file manipulation, and the launching of arbitrary programs and command line options.

(*) Note that the section on “Internet Explorer Security Levels” is about fifteen years old and is a bit out of date. (Here, “a bit” should be read as a polite euphemism for “extremely”.)

Why have developers ever relied on relaxing this setting?

Quite frankly, it was easy and even natural to relax the setting.  Business workflows often require the creation of Microsoft Office documents.  But back when many of these applications were developed, there was only so much that you could do with HTML and script, and Microsoft provided no server-side solutions for generating Office documents.  However, Office applications did (and still) have very rich client-side interfaces that are incredibly easy to use from VBScript or JScript, and even come with a full-featured macro programming environment that makes it even easier to write that script.

On top of that, using ActiveX “not marked as safe” has not always been forbidden.  In Internet Explorer 6 and earlier, the Trusted Sites zone was configured with the “Low” security level template and was almost completely wide open.  In Trusted Sites, the default setting for “Initialize and script…” was set to “Prompt”, not to “Disable”.  When client-side script in a Trusted Sites page invoked an “unsafe” ActiveX, IE displayed the dialog shown below to the user.  If the user clicked “Yes”, the ActiveX would run.

So what do you suppose users did?  Do you think the text in the dialog box made any sense to them, if they bothered to read it at all?  “An ActiveX control on this page might be unsafe to interact with other parts of the page.”  Gosh!  What other parts?  The green banner?  The disclaimer near the bottom?  The company logo?  Asking end users to make security decisions is rarely a good idea, and doing so without providing any useful information is silly.  Users learned to read the question as, “Do you want this web page to work correctly so you can do your job?” and always to click “Yes” – on that and all other such dialogs.  Users also asked, “Can you please get rid of those annoying and time-wasting prompts?” which was easily accomplished by changing the setting from “Prompt” to “Enable”.  Doing so did not degrade security because users were trained always to click Yes anyway.

So what’s wrong with enabling this setting?

There are a significant number of businesses with important web apps that rely on being able to use Word, Excel or other ActiveX components not marked as safe for scripting.  Why not just continue to allow them to work?

The problem is that there is no way to restrict the setting to apply only to “these specific ActiveX components and only for these specific purposes.”  When you enable the setting in a security zone, you allow any and all web sites in that zone to perform any actions on users’ computers that the user would be allowed to perform, silently and without the user’s knowledge or consent.  That means anyone who can control any content – any file – on any web server in that entire zone can easily mount a successful attack on all site visitors’ computers.  The attacker could install spyware (yes, malware can be designed not to require administrative rights), configure programs to run whenever that user logs on, capture and send private information to an external recipient, delete calendar appointments, or modify or delete files.  (If the end user has administrative rights, the computer now belongs entirely to the attacker.)  The attacker can do all this while being nearly impossible to trace.  For example, an attacker could add a few lines of script to an HTML file for a day, infect hundreds or thousands of users, and then restore the original HTML before anyone knew they were infected.  Good luck tracing that back to a root cause.

Show me the demo, then.

Let’s take a look.  Here is a simple HTML file hosted on a web server in the Intranet zone.  There’s nothing much to it, except that it references a separate script file, like most HTML files do these days:

What happens if someone adds just a few unfriendly lines into that script file, or into another script file that the first script file references, or yet another deeply obscured and embedded bit of content in the site?  How much work does it take to create havoc?  Here are a few lines that create ten batch files on the user’s desktop and then launch them along with ten instances of Calculator.  If this script actually runs, it will be noisy and obvious.  (Don’t count on real-life malicious actors being so courteous.)

Let’s browse the site, first with the Intranet zone’s default setting disabling the use of unsafe ActiveX.  As you can see, the result is that nothing particularly bad happens, except that Internet Explorer shows an error icon in status bar (lower left corner).  If we are very curious we can double-click on that error icon to find out a little about what went wrong (see the next graphic).  If we are turbo-nerds we might even understand what “Automation server can’t create object” means.  In any case, no harm.

Now let’s configure the security setting to the insecure “Enable” setting and browse the site again.  The results are markedly different this time.  Attacker-controlled files are being dropped on the desktop, and programs are being launched as the logged on user and can perform any actions the user is allowed to perform.

But we have had the setting enabled for years with no problems!

Well, perhaps you have!  Two questions for you, though: 

1. If the setting had been abused in the past, are you quite certain that you would have known about it?  Are you sure that strange problems that have occurred over the years were not due to abuse of this setting?
2. Given how easy it is to exploit without detection, are you quite certain that if you leave it enabled that it won’t be abused in the future?  In the near future?  By tomorrow?

Given the legitimate concern today about targeted attacks, insider threats, and “Advanced Persistent Threats” (APTs), leaving a door this wide open seems foolhardy.

How can I check whether it is enabled in my environment?

“Initialize and script ActiveX controls not marked as safe for scripting” can be configured separately for each security zone through Group Policy (Computer Configuration or User Configuration), through Machine Preferences or through User Preferences, as described in this post.  That post also describes the precedence rules that determine which of those settings takes effect.  I also recently discovered that when machine preferences are in effect there are separate settings for 32- and 64-bit processes.  So just considering the Intranet and Trusted Sites zones, there are up to ten separate registry locations that could need to be checked.

Under each of these registry keys, the “1” subkey contains settings for the Local Intranet zone and the “2” subkey contains settings for Trusted Sites.  In those subkeys, the registry value named “1201” corresponds to the “Initialize and script…” setting.  A setting of 3 means “Disabled” (preferred); 1 means “Prompt” and 0 means “Enabled.”  You can query these locations using the built-in command line utility reg.exe using this syntax:

reg.exe query "hklm\software\microsoft\windows\currentversion\internet settings\zones\1" /v 1201

If the key or value isn’t present then reg.exe writes an error message to its standard error pipe.  If the setting is found, the result will be reported like this (where “0x3” is the desired result):

HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion\internet settings\zones\1
1201 REG_DWORD 0x3

PowerShell provides richer scripting capabilities that allow you to perform more advanced operations on the results without having to first pick out the relevant text from the output.  For example, this simple script searches for the setting in all policy and preference locations for the Intranet, Trusted Sites, Internet and Restricted Sites zones and reports any that have a configured setting different from 3:

'hkcu:\software\policies',
'hklm:\software\policies',
'hkcu:\software',
'hklm:\software',
'hklm:\software\wow6432node' |
%{ $key = $_ + '\microsoft\windows\currentversion\internet settings\zones\'
1..4 |
%{ $key + $_ }} | %{
if (Test-Path $_) {
$val = (gp $_)."1201"
if ($val -ne $nul -and $val -ne 3)
{ "Problem: 1201 is set to " + $val + " in key " + $_ }
}
}

A third and simpler option is to run the IEZoneAnalyzer utility.  Not only can you view and compare settings in a sortable view, IEZoneAnalyzer also determines the effective settings based on precedence order and policy settings.  You can also copy/paste or export results to Excel.  To group all the “not marked as safe” settings together, use the “View/Compare Entire Collections of Settings” feature and sort on the ID or Name column in the resulting view by clicking the column header.

How can I keep it from getting enabled?

You can configure the “not safe for scripting” setting in Computer Configuration or User Configuration.  The setting is in each of the security zone folders under Windows Components | Internet Explorer | Internet Control Panel | Security Page. The Group Policy editor shortens the name of the setting to “Initialize and script ActiveX controls not marked as safe”.  It’s one of those confusing settings where you need to Enable the policy in order to Disable the feature, as shown in the screenshot below.  I strongly recommend that you set it to Enabled:Disable under Computer Configuration for the Intranet, Trusted Sites, Internet and Restricted Sites Zones.  Note that while Group Policy settings are read by programs from the registry, those settings should be configured through Group Policy and not by directly manipulating the registry.

How can I fix the apps that rely on this setting?

This will be the topic of my next post.  Stay tuned!