This is the second installment in a series discussing various issues regarding the intersection of Microsoft Internet Explorer 7 and the Federal Desktop Core Configuration (FDCC).  The FDCC bears close resemblance to Microsoft’s security guidance for Windows XP and Windows Vista, so this series will be of interest to any customers who are locking down Windows and Internet Explorer.

The first post in this series covered IE’s security zones, changes made to “Trusted Sites” in IE7, preferences vs. policies, templates, and the “locked down” zones.  This post will discuss the impact of FDCC-mandated policies on typical Internet Explorer users:

Installing ActiveX

Viewing or changing security zone settings

FIPS – “System cryptography:  Use FIPS compliant algorithms…”

Prevent ignoring certificate errors

Java, and Java Permissions

User goodies

Impact of FDCC-mandated policies on typical IE users

Installing ActiveX

The single most impactful and valuable aspect of the FDCC is its mandate that users not have administrative rights on their computers.  This single requirement is what provides the greatest security and cost-reduction benefits of the FDCC.  Without this part of the mandate, the value of the rest of the required policies is minimal.  (Note that the Power Users group on Windows XP is an admin-equivalent group.  Users should not be members of this group, nor of Backup Operators.)

It must be emphasized that while FDCC expressly forbids typical users from running with elevated privileges, as of this writing there is no Group Policy setting to enforce it, nor any scanning tools that validate it.  Nevertheless, it is part of the FDCC mandate, and agencies are required to follow it.

For Internet Explorer users, the most noticeable result of running as non-admin is that they can no longer install ActiveX controls.  Non-admin users do not even get prompted when a site they have browsed to wants to install an ActiveX. 

The deployment model for ActiveX has traditionally been on-demand, and performed by Internet Explorer itself.  When a user browses to a web page that uses an ActiveX control, the page can specify the location from which the control can be downloaded and the minimum version required.  Internet Explorer checks whether the required or a newer version is installed; if not (and if the user has the necessary rights), the user will be prompted to install or upgrade the control.  The installation is performed by Internet Explorer, which runs in the security context of the logged-on user.  Installing ActiveX typically involves copying files into system-wide locations (%windir%\Downloaded Program Files), and registering settings in system-wide registry locations (HKEY_CLASSES_ROOT, which usually maps to HKEY_LOCAL_MACHINE\Software\Classes).  Non-admin users have never been allowed to do this, and so Internet Explorer long ago added a check for necessary rights so that non-admin users wouldn’t get prompted for an install they couldn’t perform.

For organizations that have used ActiveX for web-based line of business (LOB) web applications, this creates some challenges.  The ActiveX controls cannot be deployed in the traditional manner.  There are several ways to manage these challenges:

·         On Windows Vista, the ActiveX Installer Service can be configured via Group Policy to allow non-admin users to install ActiveX controls from designated sites.

·         ActiveX controls can be repackaged to be deployed through Active Directory Group Policy, SMS or another enterprise management system.

·         Internet Explorer 8 (now at Beta 2) allows an ActiveX control to be marked so that it can be installed per-user rather than per-machine, and not require admin rights to install.

·         Retire the ActiveX and reimplement the required functionality using AJAX, .NET ClickOnce or another technology that doesn’t require client admin rights.

More information about the ActiveX Installer Service (a.k.a., “AxIS”) can be found here:

·         The ActiveX Installer Service in Windows Vista (TechNet Magazine)

·         Implementing and Administering the ActiveX Installer Service

·         ActiveX Installer Service Discussion and Video (circa Windows Vista RC1)

·         KB 951585 (describes a hotfix that may be needed for some environments)

Technical information about Internet Explorer 8 can be found here:

·         Internet Explorer 8 Beta 1 Whitepapers (including Non-Admin ActiveX Controls)

Viewing or changing security zone settings

Another important aspect of FDCC (or of any locked down configuration, for that matter) is that end users make many fewer trust or security decisions.  These decisions are made instead by trained security professionals – or at least by designated system administrators who hopefully have more than just a tenuous grip on IT security concepts and issues.

Included in this set of decisions is how much trust to place in various web sites.  On unrestricted computers, users can choose which sites to treat as “Trusted site” or “Restricted sites”, and determine what sites should be treated as part of the “Local intranet”.  Users are also able to change individual security settings for each of these zones, or apply a different template to a zone (e.g., set “Trusted sites” to the Low security template as it had been prior to IE7 – not a good idea!)

With FDCC, all these decisions are removed from end users.  The primary policy which enforces this is “Security zones:  Use only machine settings”:  User Policies and Preferences for security zones are ignored in favor of Machine Policies and Preferences, and the same settings apply to all users of the computer.  The IE security zone settings that FDCC requires are implemented as Machine Policies.  Since users are not allowed to change any system-wide configuration settings, this setting blocks users from adding or removing sites from the Trusted sites, Restricted sites and Local Intranet zones, from changing the security level of or individual security settings within any of the zones.  Consequently, another effect of this setting is that most of the standard UI for viewing or changing IE security zone settings is disabled:

One drawback is that users (and admins) cannot use this dialog to see what the effective security settings are for a given zone.  “IE Zone Compare” is a new tool that makes that information visible.  It will be posted on this blog later in the “FDCC and Internet Explorer 7” series.

(Two related settings are “Do not allow users to add/delete sites” and “Do not allow users to change policies”.  However, the “Use only machine settings” policy combined with users not having admin rights ends up having the same effect, but more completely and effectively.)

FIPS – “System cryptography:  Use FIPS compliant algorithms…”

FDCC mandates that only FIPS compliant algorithms be used for all cryptographic operations.  It’s actually more than FDCC – the law has required this of Federal agencies for many years.  The main impact this policy has for Internet Explorer users is that HTTPS sites must use the TLS 1.0 protocol (sometimes known as SSL 3.1).  SSL 3.0 and earlier are not FIPS compliant.  Internet Explorer (and other Schannel clients) cannot negotiate a connection with sites that use SSL 3.0 or earlier.  The symptom of this failure is the same that you’d get if the site were down completely:  IE6 says “The page cannot be displayed” (“The page you are looking for is currently unavailable…”); IE7 displays “Internet Explorer cannot display the webpage” (“Most likely causes:  You are not connected to the Internet…”).

Using TLS 1.0 requires the cooperation of the browser and the web server.  On the browser side, make sure that the “Use TLS 1.0” option is checked on the Advanced tab of the Internet Options dialog.  Note that on IE6 this is not checked by default (it is on by default in IE7).  Unfortunately, there is no Group Policy to control this setting.

See the following Knowledge Base articles for more information about the effects of the FIPS setting:

·         KB 811833:  The effects of enabling the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting in Windows XP and in later versions of Windows

·         KB 811834:  PRB: Cannot visit SSL sites after you enable FIPS compliant cryptography

Prevent ignoring certificate errors

Draft versions of the FDCC GPOs required that “Prevent ignoring certificate errors” be enabled.  Because of the huge amount of usability impact, this requirement was removed from FDCC Major Version 1.0, which was released on June 20, 2008.  In other words, this setting is no longer required by FDCC.  Get the latest SCAP content from fdcc.nist.gov to make sure that your compliance scans don’t flag this setting as missing or misconfigured.

When you browse an HTTPS site, Internet Explorer verifies the server’s digital certificate:  it has to match the name of the site you’ve requested, it has to come from a trusted certificate authority, and its validity period must be current.  If any of these verifications fail, the user is warned that something is amiss, as shown in this screenshot below.  Ordinarily, the user is given the option to ignore the certificate error and to browse to the site anyway:

Continuing to the site is not recommended, because you don’t have assurance that the site is who they claim to be.  Anybody can create a self-signed server authentication certificate that claims to be bankofamerica.com – but only the real Bank of America should be able to get a bankofamerica.com server authentication certificate from a trusted certificate authority.

When the “Prevent ignoring certificate errors” policy is enabled, the decision to continue to a potentially bad site is taken out of the user’s hands – the option to “Continue to this website” is removed, and the user cannot browse to the page:

This policy setting is security goodness, but FDCC removed the requirement to enable it because it turns out that within the government there are a lot of internal sites and network appliances that have self-signed certificates.  There are also issues with certificate names:  if the server name in the certificate says “sharepoint.internal.agency.gov”, then you can’t browse to https://sharepoint – you have to use the fully-qualified domain name.  Similarly, if the name in the certificate is just “sharepoint”, then there is no way to get there if you have to use the FQDN to resolve it.

Note that “Prevent ignoring certificate errors” is a completely separate issue from the FIPS issue.

Java, and Java Permissions

The “Java Permissions / Disable Java” setting that had been applied to all security zones in draft versions of the FDCC caused some unintended problems, as we described here.  FDCC Major Version 1.0 changes the setting to “High safety” for the Intranet and Trusted Sites zones, so non-Microsoft Java should be able to run in those zones.

Sun Java can have problems running in Internet Explorer Protected Mode on Windows Vista.  Recommendations about Protected Mode will be the topic of the next post in this series.

User goodies

FDCC disables auto-complete in forms and will not save passwords typed into forms or authentication dialogs.

FDCC disables 3^rd party browser extensions.  This disables toolbars like MSN’s and Google’s, and integration with Acrobat Reader and instant messaging programs.  Hopefully it will also block a lot of the malware and spyware that is implemented as browser helper objects, toolbars, etc.

This multi-part series will discuss various issues regarding Microsoft Internet Explorer 7, particularly with regard to its use on Federal Desktop Core Configuration (FDCC) compliant systems.  The FDCC is based on Microsoft’s security guidance for Windows XP and Windows Vista, so this series will likely be of interest to audiences beyond those impacted by FDCC.  Topics that will be covered include:

·         Primer on IE security zones and how they are controlled and used, including the "Locked Down" zones.

·         Impact of FDCC-mandated settings on typical IE users.

·         Recommendations regarding "Protected Mode" on Windows Vista.

·         Discussion of a bug that impacts the Local Machine zone (a.k.a., the "Computer" zone) on FDCC-compliant Vista computers.

·         Introduction of a new tool, IEZoneCompare, to visually identify and compare effective IE security zone policies and preferences.

Internet Explorer Security Zones

In this article:

Zones and Policies

Templates

Local Intranet Zone vs. Trusted Sites Zone

The "Locked Down" Security Zones

Zones and Policies

There are many capabilities that can be leveraged by a web browser beyond rendering static HTML.  These capabilities can include the ability to run script, to invoke installed mobile code (such as Java or ActiveX), and to manipulate the clipboard.  Permission to use some of these capabilities should be granted only to trustworthy content.  The concept behind IE security zones is that the source of the content to be rendered by the browser – in other words, where the content came from – can be used to help determine the trustworthiness of that content.  Zones that are defined by Internet Explorer include:

·         Local Machine (a.k.a., "Computer" or "My Computer") zone is for content that is already found on the local computer (but not in the Temporary Internet Files cache).  In the past this had been considered the most trusted content; this was changed by the "Local Machine Zone Lockdown" feature first introduced in Windows XP SP2, and which is described in more detail below.

·         Local Intranet zone is for content found on the organization’s intranet.

·         Internet zone is for content found on the Internet – this is considered an untrustworthy source for content.

·         Trusted Sites are for external sites that are explicitly determined by the user or by the administrator to be more trustworthy than other content on the internet.

·         Restricted Sites are for sites that are explicitly determined by the user or by the administrator to be less trustworthy than other content on the internet.

Registry settings determine which capabilities are permitted for each zone.  There are dozens of these settings, which are documented in KB 182569.  For example, the value "1201" maps to the permissions for "Initialize and script ActiveX controls not marked as safe."  These zone settings can be defined in multiple places, with a hierarchy determining which settings are actually in effect:

·         Machine Policies (HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones)

·         Machine Preferences (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones)

·         User Policies (HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Zones)

·         User Preferences (HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Zones)

Under each of these "Zones" keys are subkeys for each of the security zones:

·         0:  Local Machine

·         1:  Local Intranet

·         2:  Trusted Sites

·         3:  Internet

·         4:  Restricted Sites

The default precedence order for settings for a particular zone is:

·         Machine Policies

·         User Policies

·         User Preferences

·         Machine Preferences

Policies always take precedence over Preferences, so if a registry value exists for a capability in a Policies key, it will override a corresponding setting in a Preferences key for that zone.  In a default Windows install, no Policies keys are populated, so only Preferences are in effect.  FDCC mandates a bunch of Policies settings, particularly for the Internet zone.  Note that all the User Policies keys (starting in HKCU\Software\Policies and HKCU\Software\Microsoft\Windows\CurrentVersion\Policies) are read-only to non-admin users – even though they are in HKCU.  Policies are hard to enforce if you let users overwrite them.

Also note that the correct way to populate the Policies is through Group Policy interfaces, not by pushing data directly into those registry keys.  The Group Policy interfaces (whether programmatic or interactive tools) ensure that the Group Policy stores (registry.pol files) contain the authoritative settings, and that the GP hierarchy (domain vs. OU vs. local policies) is respected.  If you apply settings directly into the registry, they will likely get overwritten or deleted upon the next Group Policy refresh.

By default, User Preferences take precedence over Machine Preferences.  By default, Machine Preferences come into play only when a corresponding value does not exist in the User Preferences.  However, there is a group policy, "Security Zones: Use only machine settings", which FDCC mandates.  With this policy in effect, User Policies and Preferences are ignored – only the Machine Policies and Preferences are used.  This helps ensure that non-admin users do not override administrative security choices.

Note that the Security tab of the Internet Properties dialog shows User Preferences only.  And when Policies are in effect, most or all of the Security tab UI is disabled, with a label at the bottom explaining, "Some settings are managed by your system administrator".

Templates

"Templates" define a collection of settings that can be applied to a zone as a comprehensive group.  These collections appear in the IE Security tab as security levels "High", "Medium-high", "Medium", "Medium-low", and "Low".  When you set a particular zone to one of these levels, it copies the settings for that template to the User Preferences for that zone.  The Template settings are defined in the registry in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\TemplatePolicies.

Local Intranet Zone vs. Trusted Sites Zone

Originally, the "Trusted Sites" zone was treated as the most trustworthy of all the zones.  It was configured to use the "Low" security level template, while "Local intranet" was set to "Medium-low".  Starting with Internet Explorer 7, however, security on "Trusted Sites" was tightened up, and it now defaults to the "Medium" security level template.  So now, "Local Intranet" has more relaxed permissions than "Trusted Sites".  It is recommended to use the "Intranet" zone for internal sites, and "Trusted Sites" for trusted external sites.

For organizations that had added their dotted-name intranet sites to the "Trusted Sites" zone and are using default permissions for that zone, one very notable impact is that browsing IIS web sites that use Windows authentication now prompts for credentials rather than just using the Windows logon of the user to flow through.  This is because the "Logon options" security setting for "Medium-low" and above sends credentials automatically only in the Intranet zone (see screenshot).

When Trusted Sites was based on the "Low" template, the Logon option defaulted to "Automatic logon with current user name and password."  But generally you do not want Internet Explorer to try to log on automatically with the user’s current username and password to an external site, even a "trusted" one.

By default, URLs in which the server name contains dots are assumed to be in the Internet zone, even if they are on your organization’s intranet; e.g., http://hrweb.contoso.com.   One way to define the fully-qualified domain names (FQDNs) that should be considered intranet is through the "Site to Zone Assignment List" in Group Policy (Computer Configuration \ Administrative Templates \ Windows Components \ Internet Explorer \ Internet Control Panel \ Security Page).  For more information on zone detection algorithms, see this page:  http://msdn.microsoft.com/en-us/library/bb250483(VS.85).aspx.

The "Locked Down" Security Zones

Those who have dug into Group Policy for Internet Explorer and/or the details of FDCC configuration have probably noticed that in addition to the standard zones ("Internet", "Intranet", etc.), there are corresponding "Locked-Down" zones, with their own collections of settings:

The Policies and Preferences for these zones live in "Lockdown_Zones" keys near the corresponding machine and User Policies and Preferences:

·         Machine Policies:  HKLM\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones

·         Machine Preferences:  HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones

·         User Policies:  HKCU\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones

·         User Preferences:  HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Lockdown_Zones

The "Locked-Down Local Machine Zone" is very different from the other "Locked-Down" zones.

The Lockdown_Zones settings for the Local Machine zone (zone 0) are used by a feature first introduced in Windows XP Service Pack 2 called "Local Machine Zone Lockdown" (LMZL).  By default, when a page is opened in the Local Machine zone, it runs with the more restrictive policies/preferences in the Lockdown_Zones\0 registry keys, rather than the usual Zones\0 settings.  By default, the LMZL settings disable ActiveX and script.  If the content in the page tries to use ActiveX or script, the information bar prompts the user whether to allow them to run.  If the user allows the blocked content, Internet Explorer then uses the less-restrictive, normal Local Machine zone policies/preferences from that point forward for the lifetime of that browser tab (for IE7+) or browser window (IE6).

You can find more information about LMZL on the following pages:

·         http://technet2.microsoft.com/WindowsVista/en/library/44a2d577-3ee5-4b44-9af7-aaebcfcf41341033.mspx

·         http://technet2.microsoft.com/windowsserver/en/library/aebcfc94-25d5-4f41-93cc-7fb6e031de401033.mspx

The Lockdown_Zones settings for the other zones (Intranet, Internet, etc.) are used to support a feature called "Network Protocol Lockdown" (NPL).  This can be used to force content received over less-commonly used URL schemes to be provided restricted permissions.  http: and https: are the most common URL schemes.  Less common schemes include ftp:, file:, mailto:, shell:, and application-defined pluggable protocols.  NPL restrictions are off by default, but administrators may choose to enable lockdown zones for specific applications and URL schemes to help reduce attack surface.

More information about NPL can be found here:

·         http://technet2.microsoft.com/windowsserver/en/library/44a1af75-935b-4cc2-97cd-da3b7e8bfc891033.mspx