FDCC and Internet Explorer 7, Part 3 – Protected Mode

This is the [long-delayed] third 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. The second post discussed the impact of FDCC-mandated policies on typical Internet Explorer users. This post discusses the impact of Protected Mode on Windows Vista.

The two main issues covered here are:

1. While Protected Mode improves security against web-based threats, it can cause some application compatibility problems with line of business web applications.

2. There is a bug in the default configuration for IE7 that can inadvertently enable Protected Mode in the Computer zone, which can break more stuff.

Windows Vista enhanced its security infrastructure with Mandatory Integrity Control, which makes Internet Explorer’s “Protected Mode” possible. To summarize, IE in Protected Mode runs in a process with a constrained security context that prevents the process from modifying most areas of the file system and registry, including those areas that the user is normally allowed to modify, such as the user’s Startup folder. Protected Mode is intended to serve as a defense in depth measure, so that if malware from the internet manages to exploit a browser vulnerability, it will be much harder for the attacker to make changes to the user’s system.

Protected Mode is a per-zone setting. It is enabled by default for the Internet and Restricted Sites zones, disabled for the Trusted Sites and Local Machine (a.k.a., “Computer”) zone. The Intranet zone has Protected Mode enabled by default in IE7, but disabled by default in IE8. I’ll explain that change in a moment.

With Internet Explorer 7, all the tabs within a window frame are managed by a single process. Because Protected Mode is an attribute of the process, everything displayed within a particular IE7 window is either Protected Mode ON or Protected Mode OFF. So if the user navigates from a zone where PM is enabled to one where PM is disabled (or vice versa), IE7 needs to open a new window, and displays this dialog:

This is admittedly not the greatest experience from the user’s perspective. Internet Explorer 8 was re-architected so that individual tabs within a window frame can be managed by separate processes which can be swapped out as needed, so navigating between PM-enabled and PM-disabled is now seamless.

The reason that Protected Mode was enabled for the Intranet zone in IE7 was not for any security benefit. The Intranet zone, after all, is the most permissive of the zones, allowing the use of more browser-based programming techniques than do the other zones. For example, the pop-up blocker is disabled only in the Intranet zone. The reason that IE7 turns on Protected Mode for the Intranet zone is only to avoid having to switch windows when navigating between the Internet and Intranet zones, which the designers assumed would be the most used zones in the enterprise.

As long as the web app you’re using uses only standard HTML, DHTML, AJAX, etc., it usually doesn’t matter whether it is in Protected Mode or not. But if you have mobile code (e.g., ActiveX or Java) that expects to be able to write to the file system or registry, Protected Mode can cause your app not to work as expected. Since custom ActiveX and Java is common with line of business (LOB) web applications, this can lead to a significant number of application compatibility issues.

When this is the case, it is worth considering disabling Protected Mode for the Intranet zone. It is possible to rewrite the custom code to work in Protected Mode, for example by leveraging external broker applications as described in the MSDN article, Understanding and Working in Protected Mode Internet Explorer. However, this can be complex, time-consuming and expensive. Given that IE8 already disables Protected Mode for the Intranet zone, it is far simpler just to disable it for IE7 as well. Upgrading to IE8 is another alternative worth considering.

Also, if the sites that users spend the majority of their time in are in the Intranet and Trusted Sites zones, turning off Protected Mode for the Intranet zone reduces the number of window switches as well.

Having said that, let me make very clear that it is strongly recommended that Protected Mode always remain enabled in the Internet and Restricted Sites zones. If you have external sites that are business-critical and that fail with Protected Mode (e.g., due to use of Java), they should be added to the Trusted Sites zone.

Here is how to disable Protected Mode in the Intranet zone through Group Policy:

Policy location: Computer Configuration \ Administrative Templates \ Windows Components \ Internet Explorer \ Internet Control Panel \ Security Page \ Intranet Zone

Setting: Turn on Protected Mode

State: Enabled: Disable (see the screenshot, below)

Bug in Default Settings for Protected Mode for the Local Machine Zone

There are numerous places where IE security zones can be configured: for each of the five zones, there are machine-wide policies and preferences; per-user policies and preferences; and then corresponding “lockdown” zones for each of those, of which the most important is the Local Machine Zone Lockdown (LMZL). For more information about these topics, see FDCC and Internet Explorer 7, Part 1: Security Zones.

Protected Mode is not intended to be used in the Local Machine (a.k.a., Computer) zone, and it is set to Disabled in all the places where it can be configured – with one exception. Due to an oversight, the default configuration of IE7 enables Protected Mode in the machine preferences for the LMZL. As described in Part 1 of this series, machine preferences normally have no effect – unless the “Security Zones: Use only machine settings” Group Policy setting is enabled, as it is in the FDCC, and in Microsoft’s security guidance for Windows. The Protected Mode setting remains in effect when transitioning from the Locked-Down LMZ to the normal LMZ, since unlike the other zone settings it cannot be changed without switching to another process.

As described in the previous section, Protected Mode can cause app breakage when the app expects to be able to write to the file system or registry. Common examples we’ve seen are failures with “print preview” and similar functionality where the preview content has been written to and then opened from the local hard drive.

When IE8 is installed, the setting is corrected. For IE7, the change has to be applied directly. Here are the specifics:

Key: HKLM \ Software \ Microsoft \ Windows \ CurrentVersion \ Internet Settings \ Lockdown_Zones \ 0

Value name: 2500

Change the value from 0 to 3.

You can also fix the problem through Group Policy:

Policy location: Computer Configuration \ Administrative Templates \ Windows Components \ Internet Explorer \ Internet Control Panel \ Security Page \ Locked-Down Local Machine Zone

Setting: Turn on Protected Mode

State: Enabled: Disable (see the screenshot, below)