Export (0) Print
Expand All

Appendix: Windows XP Service Pack 2 Enhancements to Internet Explorer 6

Published: August 18, 2004

On This Page

Introduction
New Internet Explorer Features
Download, Attachment, and Authenticode Enhancements
Add-on Management and Crash Detection
Binary Behaviors Security Setting
BindToObject Mitigation
Information Bar
Feature Control Security Zone Settings
Local Machine Zone Lockdown
MIME Handling Enforcement
Object Caching
Pop-up Blocker
Untrusted Publishers Mitigations
Window Restrictions
Zone Elevation Blocks
Network Protocol Lockdown
New Group Policy Settings Affecting Internet Explorer

Introduction

As part of a major effort to increase the security of desktop computers, in summer 2004, Microsoft is releasing an update to Microsoft® Windows® XP named Windows XP Service Pack 2. As with all Windows service packs, Windows XP Service Pack 2 includes all of the critical updates released for Windows XP to date. In addition, Service Pack 2 includes a large number of new enhancements to Windows XP—enhancements aimed at increasing the default level of security for the operating system.

Security enhancements to Microsoft® Internet Explorer provide improved protection against malicious content on the Web and also provide interface enhancements that make configuring security easier for administrators and end users. A new Information Bar consolidates many of the dialog boxes Internet Explorer uses to provide information to users. For the first time in its history, Internet Explorer now includes a built-in pop-up window blocker. Also, several new settings have been added to the Security Zones available in Internet Explorer.

New Internet Explorer Features

New features introduced to Internet Explorer by Windows XP Service Pack 2 include the following:

  • Download, Attachment, and Authenticode Enhancements

  • Add-on Management and Crash Detection

  • Binary Behaviors Security Setting

  • BindToObject Mitigation

  • Information Bar

  • Feature Control Security Zone Settings

  • Local Machine Zone Lockdown

  • MIME Handling Enforcement

  • Object Caching

  • Pop-up Blocker

  • Untrusted Publishers Mitigations

  • Window Restrictions

  • Zone Elevation Blocks

  • Network Protocol Lockdown

Each of these features is covered in the following sections.

Download, Attachment, and Authenticode Enhancements

Feature Goal

Windows XP Service Pack 2 changes the prompts that are used for file downloads, mail attachments, shell process execution, and program installation to be both more consistent and clearer than they were in Windows XP Service Pack 1. In addition, Windows XP displays the publisher of an executable file when a user selects executable files in either Internet Explorer or Microsoft® Outlook® Express.

Windows XP Service Pack 2 provides a new application programming interface (API) that allows application developers to make use of this new user interface. Application developers will be able to call the new Attachment Execution Services (AES) dialog box from their Windows applications. Application developers should also be aware that Windows will check executable files for signatures when those files are downloaded or attached to an email message.

These changes bring consistency and clarity to the experience of downloading files and code to a user’s computer. The publisher check provides crucial information when Windows locates a signature in an executable file and provides a systematic way to prevent executable files that are from suspicious or unidentified publishers from compromising the security of a computer.

Feature Details

Internet Explorer File Download Prompt

When a user uses Internet Explorer to download a file, the dialog box that appears has the following changes:

  • A file handler icon has been added.

  • A new information area has been added to the bottom of the dialog box that provides slightly different information, depending on whether the downloaded file type is of higher or lower risk.

  • All executable files that are downloaded are checked for publisher information.

After downloading an executable file, Internet Explorer displays the publisher information of the file. The Authenticode dialog box presents this information to the user, who can then make a more informed decision about running the file. An executable file that does not include a publisher signature, has an invalid publisher, or whose publisher has been blocked by a systems administrator will not be allowed to run on the computer. Executable files with invalid or blocked signatures are not allowed to run. You can unblock a publisher by using the Manage Add-Ons command in Internet Explorer.

Outlook Express Email Attachment Prompt

The Outlook Express email attachment prompt uses the same procedures as file downloads. Executable files are checked for a publisher, and an executable file that does not include a publisher signature, has an invalid publisher, or whose publisher has been blocked by a systems administrator is not allowed to run.

Add-On Install Prompt

The Internet Explorer add-on install prompt adds the same information as described in the previous two sections. This enables users to know exactly which add-ons they are incorporating into Internet Explorer and to make an informed decision about their use.

To allow the installation of controls with an invalid signature, use the following procedure:

  1. In Internet Explorer, on the Tools menu, click Internet Options, and then click the Security tab.

  2. In the Security level for this zone box, click Custom Level.

  3. Select the Allow installation of ActiveX controls that have invalid signatures check box.

    Caution   When a signature is invalid, you cannot trust that the publisher is asserting a truthful identity. Allowing installation of ActiveX controls that have invalid signatures is not recommended and introduces additional risk to your computer.

Add-on Management and Crash Detection

Feature Goal

Add-on management and crash detection are two new, closely-related features that are included in Internet Explorer.

Add-on Management allows users to view and control the list of add-ons that Internet Explorer can load with more detailed control than before.

Internet Explorer Add-on Crash Detection attempts to detect crashes in Internet Explorer that are related to an add-on. When Internet Explorer successfully identifies an add-on that is causing trouble, it presents this information to the user. The user has the option of disabling add-ons to diagnose frequent crashes and improve the overall stability of Internet Explorer.

Users will be able to view, enable, and disable the add-ons used by Internet Explorer and identify add-ons that might be related to Internet Explorer crashes. Administrators can enforce a list of add-ons that are allowed or disallowed and restrict the ability of users to manage add-ons.

Windows Error Reporting data has shown that add-ons are a major cause of stability issues in Internet Explorer. These add-ons significantly affect the reliability of Internet Explorer. These add-ons can also pose a security risk because they might contain malicious and unknown code.

Many users are unaware of the add-ons they have installed on their computer. Some add-ons are loaded whenever Internet Explorer is started but cannot be detected unless the user searches the registry. When users experienced frequent crashes, there was no easy way to diagnose whether the issue was related to an add-on. Even if they suspected that the problem stemmed from recently installed software, it was difficult to isolate the cause and often impossible to fix if the software did not provide an uninstall option.

Feature Details

Internet Explorer Add-on Management, together with Add-on Crash Detection, gives users the ability to improve the security and stability of their systems by identifying and disabling problematic add-ons. Administrators are also provided with a powerful administrative tool to control add-on use in their organization.

Internet Explorer Add-on Management

Internet Explorer Add-on Management allows users to view and control the list of add-ons that can be loaded by Internet Explorer with more detailed control than before. It also shows the presence of some add-ons that were previously not shown and could be very difficult to detect. These add-ons might provide undesired functionality or services and, in some cases, might present a security risk.

For example, a user might unintentionally install an add-on that secretly records all Web page activity and reports it to a central server. Previously, specialized software and deep technical knowledge might have been required to identify and remove that add-on. Internet Explorer Add-on Management provides an easier way to detect and disable that add-on.

Add-ons include:

  • Browser Help objects

  • ActiveX controls

  • Toolbar extensions

  • Browser extensions

Add-ons can be installed from a variety of locations and in several ways, including:

  • Download and installation while viewing Web pages

  • Installation by the user by way of an executable program

  • As pre-installed components of the operating system

  • As pre-installed add-ons that come with the operating system

Managing Add-ons

Users can enable and disable each add-on individually and view information about how often the add-ons have been used by Internet Explorer. To do this, use the following procedure to open Manage Add-ons.

  1. Click Start, and then click Internet Explorer.

  2. Click View, and then click Manage Add-ons.

You can also open Manage Add-ons through Control Panel by following these steps:

  1. Click Start, and then click Control Panel.

  2. Double-click Internet Options.

  3. Click the Programs tab, and then click Manage Add-ons.

Manage Add-ons has several options that allow you to change your add-on configuration. You can use Show to control the way in which the add-ons list is displayed. It has two options:

  • Add-ons currently loaded in Internet Explorer. This option lists the add-ons that have been instantiated (or loaded into memory) within the current Internet Explorer process and those that have been blocked from instantiating. This includes ActiveX controls that were used by Web pages that were previously viewed within the current process.

  • Add-ons that have been used by Internet Explorer. This option lists all add-ons that have been referenced by Internet Explorer and are still installed.

The list of add-ons shows all installed add-ons of the types mentioned earlier in this document. To enable or disable an installed add-on, click the add-on in the list, then click Enable or Disable.

If you click an ActiveX control in the list, then click Update ActiveX, Windows searches for an update at the location where the original control was found. If a newer version is found at that location, Internet Explorer attempts to install the update.

The list of add-ons also contains signed add-ons that were blocked from installation because their publisher was untrusted. If you select one of these controls, the user can unblock the control by clicking Allow. Users should exercise caution when doing this, though, because clicking Allow removes the publisher from the Untrusted list.

Blocked Add-on Status Bar Icon

A Blocked Add-on icon appears in the status bar when a Web page attempts to instantiate an ActiveX control that is disabled or blocked because its publisher is untrusted. You can double-click the icon to open Manage Add-ons. The status bar icon is accompanied by a balloon tip the first five times it appears.

Add-on Notification Balloon Tip

When a Web page attempts to instantiate a disabled add-on and there is no current Blocked Add-on status bar icon, a message appears to tell the user that the current Web page is requesting an add-on that is disabled. The user can click the message for more details on blocking add-ons.

Internet Explorer Add-on Management for Administrators

The new features for allowing and disallowing add-ons work in conjunction with existing policies for managing ActiveX controls and allow administrators to control the usage of the new features. Add-on disabling is applied on top of existing checks and does not replace other security restrictions that might be in place. For example, if an ActiveX control is blocked by its ActiveX compatibility flags, it will always be blocked, regardless of the add-on management settings.

In the event that adding these policies removes needed functionality, remove the policies that were applied and restart Internet Explorer.

Disabling Crash Detection

When Crash Detection is disabled, a crash in Internet Explorer exhibits the behavior of earlier versions, which is usually to invoke Windows Error Reporting. All policies for Windows Error Reporting continue to apply.

Disabling Add-on Management User Interface

When the Add-on Management user interface is disabled, the following features are hidden from the user:

  • Manage Add-ons menu item

  • Manage Add-ons Control Panel icon

  • Manage Add-ons status bar icon when an ActiveX control is blocked

  • Manage Add-ons message when an ActiveX control is blocked

Allow and Deny Policies

Administrators can control the use of add-ons in much the same way that users control add-ons. There are three modes of operation:

  • Normal mode. The user has full control of which add-ons are enabled and disabled. This is the default mode.

  • AllowList mode. The admin specifies the add-ons that are allowed; all other add-ons are disallowed and cannot be enabled by the user.

  • DenyList mode. The admin specifies the add-ons that are disallowed; all other add-ons can be controlled by the user.

To populate the AllowList or DenyList policies, create and populate the appropriate registry keys as described in the section "Setting Changes in Service Pack 2" later in this document. Below each registry key described (AllowList and DenyList), create a subkey for each CLSID key in the list. For example, you might create the following key to deny a control:

HKCU{LM}\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\
Ext\DenyList\{42D39483-D56E-48FC-82A3-A67DBE6208B1}

The lists are empty by default. An empty DenyList policy is equivalent to Normal mode, where the user has full control. An empty AllowList policy causes all add-ons to be disallowed.

Note: When an AllowList or DenyList policy is in effect and the user selects an add-on from the management list that is disabled by policy, Enable and Disable are unavailable.

Internet Explorer Add-on Crash Detection

Whenever Internet Explorer stops working, the Add-on Crash Detection program is started. Add-on Crash Detection is an error-analysis program that examines the state of the Iexplore.exe (Internet Explorer) process. It collects the list of dynamic link libraries (DLLs) that are loaded, and the value of the instruction pointer register (EIP) at the time of the crash. Add-on Crash Detection then attempts to find the DLL whose memory range the EIP lies within. This DLL is often the cause of the crash.

If a DLL is found, it is not a system DLL, and the DLL is the COM server for an Internet Explorer add-on, the Internet Explorer Add-on Crash Detection window appears. This dialog box contains information that indicates which add-on caused the crash, the name of the company associated with the add-on, and the description of the DLL file that contains the add-on code. To display Manage Add-ons, which you can then use to disable the identified add-on, click Advanced. (For more information about this window and its options, see “Managing Add-ons” earlier in this document.) After you review the information and click Continue, the standard Windows Error Reporting window opens.

Feature Impact

Disabling an add-on does not remove it from the computer. It only prevents Internet Explorer from instantiating the object and executing its code. There is no guarantee that the disabled add-on will never be loaded, since an add-on that is considered by Internet Explorer to be disabled can still be used by another component in the system. The behavior that is displayed by disabling different object types varies.

  • If an ActiveX control is disabled, Web pages that rely on the control might not work as expected. They behave as if the user has uninstalled the control from the computer and declined to install it. Users are not prompted to upgrade controls that have been disabled.

  • If a Browser Helper Object is disabled, functionality that depends on the object is not available, and there is no visual indication that a component is disabled.

  • If a Browser Extension is disabled, toolbar buttons and menu entry points are not shown for that extension. Internet Explorer behaves as if the extension was not installed.

  • If a Toolbar Extension is disabled, the toolbar does not appear in Internet Explorer. There is no visual indication that the toolbar has been disabled. Internet Explorer behaves as if the toolbar was not installed.

The concept of a disabled add-on only applies to instances of Internet Explorer (Iexplore.exe) and Windows Explorer (Explorer.exe). Currently, other programs based on Internet Explorer components, such as the WebBrowser control, do not respect the disabled state.

Some software programs depend on a combination of multiple add-ons to work correctly, and disabling any one of them might cause problems. Caution should be exercised when deciding to disable one or more add-ons.

If the user disables a non-ActiveX add-on and subsequently uninstalls and then reinstalls it, the add-on might remain in a disabled state. This is because Internet Explorer is not notified of application installations and does not detect any application state changes. However, if Internet Explorer is started while the add-on is not installed, it detects a change and automatically clears the disabled state.

If the user disables an ActiveX control and then uninstalls it, the next time a Web page attempts to use the control, Internet Explorer detects that the control is no longer present and clears the disabled state. However, if the ActiveX control is reinstalled using an executable file (as opposed to a Web page download) before there are any attempts to instantiate the control, then it remains disabled. This is because Internet Explorer does not detect a state change.

In the event that disabling an add-on causes a lack of functionality, it can be restored by enabling the add-on in Manage Add-ons. Internet Explorer must be restarted for new settings to take effect, with the exception of ActiveX controls, in which reloading the affected page might be sufficient.

Setting Changes in Service Pack 2

Table 1 shows the changes in Windows XP Service Pack 2 related to Add-on Management and Crash Detection.

Table 1. Setting changes related to Add-on Management and Crash Detection

Setting Name

Location

Default Value

Possible Values

Disable Crash Detection

HKCU{LM}\Software\
Policies \Microsoft\
Internet Explorer \
Restrictions

NoCrashDetection : DWORD

0

0 — Off,

1 — On

Disable Extension Management

HKCU{LM}\Software\
Policies \Microsoft\
Internet Explorer \
Restrictions

NoExtensionManagement : DWORD

0

0 — Off,

1 — On

Management Mode

HKCU{LM}\SOFTWARE\
Microsoft

\Windows\CurrentVersion\
Policies \Ext\

ManagementMode : DWORD

0

0 — Normal,

1 — AllowList,

2 —DenyList

Allow List

HKCU{LM}\SOFTWARE\
Microsoft \Windows\
CurrentVersion\
Policies \Ext\AllowList

Empty

GUID subkeys

Deny List

HKCU{LM}\SOFTWARE\
Microsoft \Windows\
CurrentVersion\
Policies \Ext\DenyList

Empty

GUID subkeys

Binary Behaviors Security Setting

Feature Goal

Internet Explorer contains dynamic binary behaviors: components that encapsulate specific functionality for HTML elements to which they were attached. These binary behaviors are not controlled by any Internet Explorer security setting, which allows them to work on Web pages in the Restricted Sites zone. In Windows XP Service Pack 2, there is a new Internet Explorer security setting for binary behaviors. This new setting disables binary behaviors in the Restricted Sites zone by default. This new binary behaviors security setting provides a general mitigation to vulnerabilities in Internet Explorer binary behaviors.

For more information on binary behaviors, such as how they work and how to implement them, see “Cutting Edge: Binary Behaviors in Internet Explorer 5.5” on the Microsoft Developer Network (MSDN) Web site at http://go.microsoft.com/fwlink/?LinkId=21862. Note that binary behaviors, which are defined in C++ and compiled, are different from Attached Behaviors and Element Behaviors, which are defined in script.

Feature Details

A new URL action setting, Binary Behaviors, is in each Internet Explorer security zone. The default value for this setting is Enable for all zones except the Restricted Sites zone. In the Restricted Sites zone, the default value is Disable. This new setting mitigates attacks in which binary behaviors are being used maliciously and allows the user to control the use of binary behaviors on a per-zone basis. Any use of any binary behaviors for HTML rendering from the Restricted Sites zone is blocked.

Feature Impact

To use binary behaviors from the Restricted Sites zone, an application will have to implement a custom security manager. (For more information, see the “Creating a Customized URL Security Manager” section in “Introduction to URL Security Zones” on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=21863.)

When the binary behaviors URL action is exercised from a custom security manager, the URL action will pass in a string representation of the particular binary behaviors that can be enabled by that custom security manager as needed for application compatibility. The following process takes place when this URL action is exercised:

  • Internet Explorer calls into a custom security manager (if available), using the ProcessUrlAction method with a dwAction of URLACTION_BEHAVIOR_RUN.

  • The pContext parameter points to a LPCWSTR that contains the behavior that a policy is being queried for. For example, #default#time.

  • You set *pPolicy = URLPOLICY_ALLOW for your smartTag behavior from within your custom security manager, as appropriate.

In the absence of the custom security manager, the default action is to disallow running behaviors in the Restricted zone.

Application developers whose applications use Internet Explorer functionality in the Restricted Sites zone should review this feature to plan to adopt changes in their applications. For example, email applications that render HTML email in the Restricted Sites zone might need to be modified.

Users can only be impacted by applications that do not completely render HTML content with this new setting. These applications will typically alert the user that some active behavior has been blocked from display. For example, when Outlook Express encounters this situation, it informs the user that it has restricted active content in the email.

Setting Changes in Service Pack 2

Table 2 shows the new settings for turning on or off the existing binary behaviors functionality.

Table 2. New Settings for turning on or off the existing binary behaviors functionality

Setting Name

Location

Previous Default Value (if applicable)

Default Value

Possible Values

*

HKCU{LM}\Software\
Microsoft\
Internet Explorer\
Main\Feature Control\
FEATURE_BINARY_BEHAVIOR_LOCKDOWN

None

1

0 (off)

1 (on)

2000

HKCU \Software\
Microsoft \Windows\
CurrentVersion \
Internet Settings\
Zones \3\

None

3 (Disabled) for Restricted zone; 0 (Enabled)for all other zones

3 (Disabled) 0 (Enabled)

Note: The binary behaviors setting can also be modified through Group Policy as part of the Internet Explorer Security Zones and Content Ratings setting.

BindToObject Mitigation

Feature Goal

In Windows XP Service Pack 2, the ActiveX security model is applied in all cases in which URL binding is used to instantiate and initialize an object. The ActiveX security model allows controls to be marked as “safe for scripting” and “safe for initialization” and provides users with the ability to block or allow ActiveX controls by security zone, based on those settings. This allows greater flexibility and control of active content in Internet Explorer.

This feature applies to the following audiences:

  • Web developers and network administrators need to be aware of these new restrictions to plan changes or workarounds for any possible impact to their Web site.

  • Application developers should review this feature to plan to adopt changes in their applications.

  • Users could be impacted by sites that are not compatible with these stricter rules.

Feature Details

The most effective way to remove ActiveX safety vulnerabilities is to apply security policies consistently at the source of the URL binding: URLMON. Declaring an ActiveX control in an HTML page using the <object> tag and CODEBASE attribute is one commonly known example of using BindToObject. The same functionality is used by any component that wants to resolve a URL and get back a stream or object. The ActiveX security model is now applied to all object initializations with a URL as a source.

In the case of ActiveX controls, the ActiveX security model allows controls to be marked as “safe for scripting” or “safe for initialization” and provides users with the ability to block or allow ActiveX controls by zone, based on those settings. In earlier versions of Windows, this security framework was not applied in all cases in which URL binding took place. Instead, the calling code was responsible for assuring the integrity and security of the control, which could often result in security vulnerabilities. There are now a number of public exploit variations that expose this exact issue by going through Internet Explorer to compromise vulnerabilities in the calling code.

Feature Impact

The ActiveX security model is applied to all object initializations with a URL as a source, and the “Safe for initialization” tag is applied to all objects. This mitigation only applies to cases in which Internet Explorer resolves a URL and assigns it to an object.

Application-compatibility problems should be minimal. Applications can opt out if they have their own security manager. For more information on opting out of this security model, see “Security Considerations: URL Security Zones API” on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=21814.

Information Bar

Feature Goal

The Internet Explorer information bar in Windows XP Service Pack 2 replaces many of the common dialog boxes that prompt users for information and provides a prominent area for displaying information that users may want to view or act upon. Examples of dialog boxes that have been replaced by Information Bar notifications include blocked ActiveX installs, pop-ups, downloads, and active content. The information bar will provide information similar to the notification area in Microsoft® Office Outlook® 2003, which informs users of blocked content.

This feature applies to the following audiences:

  • Users who need to understand how the new behavior will affect their Web browsing experience.

  • Systems administrators who need to know how to turn this functionality on or off for the client computers in their organization.

  • Designers of Web sites that rely on add-ons, which will provide a different user experience.

  • Developers of Web-based applications who need to understand how their experience changes. For example, this affects the development of ActiveX controls. ActiveX controls that are updates to controls that are currently installed on other computers will only be treated as updates if the GUID of the new control matches the current GUID.

  • Developers of applications hosting the Web browser control will need to know how to use the new API to take advantage of this new functionality.

Feature Details

Information Bar User Interface

The information bar looks and acts in a similar way to the Outlook 2003 blocked content notification area. It appears below Internet Explorer toolbars and above the Web page in view when a notification is present and disappears on the next navigation. The text in the information bar varies, depending on the notification that is provided, and wraps to two lines if the text exceeds the bounds of the notification area. For example, a common notification message is Your current security settings prohibit running ActiveX controls on this page. As a result, the page may not display correctly. If a user controls the focus (which object in the browser can receive input) by using the TAB key, the information bar gets the focus after the toolbar and before the Web page.

In Windows XP Service Pack 2, Internet Explorer may block content that is necessary to complete certain online tasks. The information bar provides a prominent notification that informs users how to get Web pages they trust working again without the more obtrusive prompt that was provided in Windows XP Service Pack 1. Either clicking or right-clicking the information bar brings up a menu that relates to the notification that is presented. This menu always contains a link to Information Bar Help, which provides more detailed information about the notification. Additional menu items related to the notification appear above the Help menu item, but information bar menu items that are disabled by the administrator are grayed out.

Users can configure the information bar to play a sound when it appears; the default setting for the sound is On. When the information bar appears, the Windows trust icon appears in place of the Error on page notification on the status bar.

In certain cases, more than one action can be blocked. For example, a pop-up window may be blocked at the same time that an add-on install is blocked. In those cases, the text becomes more generic and the menus merge to show each action blocked at the top level, with each action’s menus in a submenu.

There is a custom security zone setting for the information bar that enables users to change the settings of the information bar by security zone. Users can choose to be notified with the information bar or to go back to the behavior of Windows XP Service Pack 1 and get a less prominent notification for file and code downloads.

Add-On Install Prompts

In Windows XP Service Pack 1, when a Web page refers to an ActiveX control that is not currently on the computer, users are asked whether they want ActiveX controls to be downloaded. In Windows XP Service Pack 2, this is displayed in the information bar. The add-on install prompts reduce the occurrences of users inadvertently installing code on their computer, either by being tricked, forced, or misled by a proposed value. Since users have an additional prompt before clicking Install, they are less likely to install an application by accident.

Trusted publishers will work as they did in Windows XP Service Pack 1. The controls that are provided by these publishers install without requiring additional configuration. Blocked publishers display the status bar icon. The control provided by these publishers will not install on the computer and does not go into the information bar.

Add-on upgrades work as they did in Windows XP Service Pack 1. To determine whether the control is an upgrade, Internet Explorer compares the certificate that was used to sign the newly downloaded .cab file with the certificate that was used to sign the currently registered server (the .dll file that is registered on the local computer as the server of the CLSID that is specified by the Web page). If the issuer and subject of the certificates are the same, the control is considered an upgrade. Upgrades exhibit the same behavior as they did in Windows XP Service Pack 1.

Pop-up Blocked Notification

Windows XP Service Pack 2 displays a notification in the information bar when a pop-up is blocked. This becomes a more obvious entry point to the Pop-up Blocker functionality, such as replaying the pop-up, adding the site to an “allow” list for pop-ups, or navigating to Pop-up Blocker settings. The information bar also provides a top-level entry point to turn off the information bar for pop-ups if the user decides the notification is too big for this event.

Showing the pop-up blocked notification in the information bar gives higher priority to that notification. Users have a better understanding of where to go to see a blocked pop-up window or to see their Pop-up Blocker settings.

Turning off the information bar for the Pop-up Blocker causes the Pop-up Blocker to return to notifying users with the status bar icon. All the same menu items are accessible from this status bar icon if the bar is disabled for pop-ups. For more information, see the section “Pop-up Blocker” later in this document.

Automatic Download Prompts

File download prompts that are launched automatically now appear in the information bar. These prompts help prevent users from installing unwanted code on their computers. Previously, sites could overwhelm users with file download prompts and, as a result, users could accidentally install unwanted software on their computer. With this change, file download prompts that are launched automatically are the result of a user’s deliberate click and not an accidental action.

Active Content Blocked

When active content is blocked from running in the Local Machine zone, the information bar will appear. In Windows XP Service Pack 2, Internet Explorer sometimes blocks active content that may be necessary to complete certain tasks. This new user interface element will ensure there is a notification that allows people to get trusted Web pages working again.

Note: The Local Machine zone mitigation will now use the new information bar. For more information, see “Local Machine Zone Lockdown” later in this document.

ActiveX Blocked Due to Security Settings

Windows XP Service Pack 2 no longer shows the prompt ActiveX Blocked Due to Security Settings. Internet Explorer now shows this notification in the information bar.

The Windows XP Service Pack 1 prompt makes browsing with heightened security settings difficult. Displaying this prompt in the information bar ensures that users can browse on high security settings without seeing the prompt. This does not cause further application-compatibility issues, other than when browsing the Internet zone with the security slider set to High.

Feature Control Security Zone Settings

Feature Goal

In an effort to help manage application compatibility for organizational intranet applications, Windows XP Service Pack 2 adds security zone settings for three new Service Pack 2 features: Multipurpose Internet Mail Extensions (MIME) sniffing (which is related to the MIME Handling feature), zone elevation, and Window Restrictions. (For more information about these features, please read the section for each feature later in this document.)

Registry settings added in Windows XP Service Pack 2 allow you to opt in to a particular security feature. In the following example, Internet Explorer has been configured to use the Window Restrictions security feature:

HKLM\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\
FEATURE_WINDOWS_RESTRICTIONS iexplore.exe=1

Once a process has been configured to use a security feature, the feature is running and security zone settings can be applied for more granularity. In the Security Settings tab of Internet Options, the user can adjust these granular settings for many of the new Windows XP Service Pack 2 feature control. If you select Enable, it lowers the security settings and allows the behavior to run less securely (or in the same manner as it did in Windows XP Service Pack 1).

Each of the Feature Controls is discussed in more detail in this document. For more information about URL Action settings and how they relate to security zones, see “About URL Security Zones Templates” on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=26001.

Using security zone settings for a feature provides additional precision in control for security features that are introduced in Windows XP Service Pack 2, and can help manage application compatibility for organizational intranet applications. A user or administrator can select different behaviors based on risk. For example, in the Internet zone, http://www.contoso.com has the Window Restrictions feature applied by default. One aspect of this feature enforces the status bar for Internet Explorer windows created with the window.open method. This security feature was added to guard against the user assuming a window was from a trusted source when it was not. However, the Windows Restriction feature is turned off by default for http://contoso on the intranet, where the risk is lower due to the typical level of corporate security. Intranet applications will continue to operate as they did in Windows XP Service Pack 1 and will not be affected by compatibility issues due to additional security restrictions.

This feature applies to the following audiences:

  • Web application developers need to be aware that the new Windows XP Service Pack 2 security settings can be dependant on the zone in which an application is run, and this can be a security consideration as well as an application compatibility adjustment.

  • Administrators of Group Policy may want to adjust the default values for each zone to suit the particular environments in their organization.

  • Unless prevented by policies in Group Policy, users can manage the values for these security zone settings (or URL actions) for each zone through Internet Options in Control Panel. Note that the Local Machine Zone is not available through Control Panel. To access the security settings for a zone, click Start, click Control Panel, click Internet Options, click the Security tab, click a Web security zone, and then click Custom Level.

Feature Details

Zone Settings for MIME Sniffing

Windows XP Service Pack 2 introduces a new feature control registry setting, FEATURE_MIME_SNIFFING, for file promotion from one type to another based on a MIME sniff. A MIME sniff is the recognition by Internet Explorer of the file type based on a bit signature. (For more information about MIME sniffing, see “MIME Handling Enforcement” later in this document.)

When this registry setting is enabled, you can use the URL action flag URLACTION_FEATURE_MIME_SNIFFING to further control the setting in each individual security zone. In Security Settings, this URL action is represented by the option Open files based on content, not file extension. This option has two possible values, Enable or Disable:

  • If you select Open files based on content, not file extension, for this Internet Explorer feature control, the zone is secured as it was for Windows XP Service Pack 1. The MIME sniffing control feature will not apply in this zone. The security zone will run without the added layer of security provided by this feature.

  • If you choose to disable this feature, the actions that may be harmful cannot run; this Internet Explorer security feature will be turned on in this zone, as dictated by the feature control setting for the process.

Table 3 lists the default values for the URLACTION_FEATURE_MIME_SNIFFING flag in each security zone:

Table 3. Default values for the URLACTION_FEATURE_MIME_SNIFFING flag in each security zone

Security Zone

Default Value

Local Machine

(not configurable through the user interface)

Enable

Trusted Sites

Enable

Intranet

Enable

Internet

Disable

Restricted Sites

Disable

Security settings are often applied to a zone by a URL security zone template. Table 4 lists Windows XP Service Pack 2 default values for the URLACTION_FEATURE_MIME_SNIFFING flag by zone template:

Table 4. Windows XP Service Pack 2 default values for the URLACTION_FEATURE_MIME_SNIFFING flag by zone template

Security Template

Value Set

Low

Enable

Medium-low

Enable

Medium

Disable

High

Disable

MIME sniffing, described elsewhere in this document, is a new feature that is introduced in Windows XP Service Pack 2. Adding security settings by zone provides more flexibility in applying the MIME sniffing security feature. This flexibility will provide a more manageable implementation of this new security feature, particularly in intranet scenarios. If the feature control setting for MIME sniffing is suspected of causing problems for an application, enabling the feature control setting in the zone where the application is running allows the administrator or user to return to Windows XP Service Pack 1 behavior in that zone while maintaining the more secure behavior in other security zones.

Zone Settings for URLACTION_FEATURE_ZONE_ELEVATION

Windows XP Service Pack 2 introduces URLACTION_FEATURE_ZONE_ELEVATION, a new feature control registry setting for mitigating many privilege escalation attacks. (For more information about Zone Elevation, see “Zone Elevation Blocks” later in this document.)

When this registry setting is on, you can use the URL action flag URLACTION_FEATURE_ZONE_ELEVATION to further control the setting in each individual security zone. In Security Settings, this URL action is represented by the setting Open Web sites can open new windows in a less restrictive Web content zone.

This URL action flag has three options, Enable, Disable, or Prompt:

  • Enable for Web sites can open new windows in a less restrictive Web content zone secures the zone as it was for Windows XP Service Pack 1. The Zone Elevation control feature will not apply in this zone. The security zone will run without the added layer of security that is provided by this feature.

  • Disable keeps the possible harmful actions from being run; this Internet Explorer security feature will be on in this zone as dictated by the feature control setting for the process.

  • Prompt causes a warning to the user that potentially risky behavior is about to occur.

Table 5 lists default values for the URLACTION_FEATURE_ZONE_ELEVATION flag in each security zone when Internet Explorer is installed on the computer:

Table 5. Default values for the URLACTION_FEATURE_ZONE_ELEVATION flag in each security zone when Internet Explorer is installed on the computer

Security Zone

Default Value

Local Machine

(not configurable through UI)

Disable

Trusted Sites

Prompt

Intranet

Prompt

Internet

Enable

Restricted Sites

Enable

Security settings are often applied to a zone by a URL security zone template. Table 6 lists default values for the URLACTION_FEATURE_ZONE_ELEVATION flag by zone template:

Table 6. Default values for the URLACTION_FEATURE_ZONE_ELEVATION flag by zone template

Security Template

Value Set

Low

Disable

Medium-low

Prompt

Medium

Enable

High

Enable

Internet Explorer Zone Elevation Blocks, described later in this document, is a new feature introduced in Windows XP Service Pack 2. Adding security settings by zone provides more flexibility in applying this feature. This flexibility will provide a more manageable implementation of this new security feature, particularly on an intranet.

If the feature control setting for zone elevation is suspected of causing problems for an application, enabling the feature control setting in the zone where the application is running will allow the administrator or user to return to Windows XP Service Pack 1 behavior in that zone while maintaining the more secure behavior in other security zones.

Zone Settings for URLACTION_FEATURE_WINDOW_RESTRICTIONS

Windows XP Service Pack 2 introduces URLACTION_FEATURE_WINDOW_RESTRICTIONS, a new feature control registry setting that restricts script-initiated pop-up windows and windows that include the title and status bars. For more information about Window Restrictions, see “Window Restrictions” later in this document.

When this registry setting is on, the URL action flag URLACTION_FEATURE_WINDOW_RESTRICTIONS can be used to further control the setting in each individual security zone. In Security Settings, this URL action is represented by Allow windows to be opened without security restrictions.

This URL action flag has two options, Enable or Disable:

  • Enabling Allow windows to be opened without security restrictions means that this zone is secured as it was for Windows XP Service Pack 1. Windows Restriction security will not apply in this zone. The security zone runs without the added layer of security provided by this feature.

  • Disabling this feature means that the possible harmful actions cannot be run; this Internet Explorer security feature will be on in this zone as dictated by the feature control setting for the process.

Table 7 lists default values for the URLACTION_FEATURE_WINDOW_RESTRICTIONS flag in each security zone when Internet Explorer is installed on the computer:

Table 7. Default values for the URLACTION_FEATURE_WINDOW_RESTRICTIONS flag in each security zone when Internet Explorer is installed on the computer

Security Zone

Default Value

Local Machine

(not configurable using Security Settings)

Enable

Trusted Sites

Enable

Intranet

Enable

Internet

Disable

Restricted Sites

Disable

Security settings are often applied to a zone by a URL Security Zone Template. Table 8 lists default values for the URLACTION_FEATURE_WINDOW_RESTRICTIONS flag by zone template:

Table 8. Default values for the URLACTION_FEATURE_WINDOW_RESTRICTIONS flag by zone template

Security Template

Value Set

Low

Enable

Medium-low

Enable

Medium

Disable

High

Disable

Internet Explorer Window Restrictions, described later in this document, is a new feature introduced in Windows XP Service Pack 2. Adding security settings by zone provides more flexibility in applying this security feature. This flexibility provides a more manageable implementation of this new security feature, particularly in the intranet.

If the feature control setting for zone elevation is suspected of causing problems for an application, enabling the feature control setting in the zone where the application is running will allow the administrator or user to return to Windows XP Service Pack 1 behavior in that zone while maintaining the more secure behavior in other security zones.

Setting Changes in Service Pack 2

Table 9 shows the changes in Windows XP Service Pack 2 related to Feature Control Security Zone Settings.

Table 9. Changes in Windows XP Service Pack 2 related to Feature Control Security Zone Settings

Setting name

Location

Default Value

Possible Values

URLACTION _FEATURE_MIME_SNIFFING

HKCU{LM}\SOFTWARE\
Microsoft\Windows\
CurrentVersion\
Internet Settings\Zones

Set per zone

Enable, Disable

URLACTION _FEATURE_ZONE_ELEVATION

HKCU{LM}\SOFTWARE\
Microsoft\Windows\
CurrentVersion\
Internet Settings\Zones

Set per zone

Enable, Disable, Prompt

URLACTION _FEATURE_ WINDOW_RESTRICTIONS

HKCU{LM}\SOFTWARE\
Microsoft\Windows\
CurrentVersion\
Internet Settings\Zones

Set per zone

Enable, Disable

Local Machine Zone Lockdown

Feature Goal

When Internet Explorer opens a Web page, it places restrictions on what the page can do, based on the page’s Internet Explorer security zone. There are several possible security zones, each with different sets of restrictions. The security zone for a page is determined by its location. For example, pages that are located on the Internet will normally be in the more restrictive Internet security zone. They might not be allowed to perform some operations, such as accessing the local hard drive. Pages that are located on your corporate network would normally be in the Intranet security zone and have fewer restrictions. The precise restrictions that are associated with most of these zones can be configured by the user through Internet Options on the Tools menu.

Before Windows XP Service Pack 2, the content on the local file system, aside from that cached by Internet Explorer, was considered to be secure and was assigned to the Local Machine security zone. This security zone normally allows content to run in Internet Explorer with relatively few restrictions. However, attackers often try to take advantage of the Local Machine zone to elevate privilege and compromise a computer.

Many of the exploits that involve the Local Machine zone will be mitigated by other changes to Internet Explorer in Windows XP Service Pack 2. However, attackers may still be able to figure out ways to exploit the Local Machine zone. Windows XP Service Pack 2 further protects the user by locking down the Local Machine zone in Internet Explorer by default. Local HTML hosted in other applications will run under the less restrictive, previous default settings of the Local Machine zone unless that application makes use of Local Machine Zone Lockdown.

Administrators will be able to use Group Policy to manage Local Machine Zone Lockdown and more easily apply it to groups of computers.

This feature applies to the following audiences:

  • All application developers should review this feature. Applications that host local HTML files in Internet Explorer are likely to be impacted. Developers of standalone applications that host Internet Explorer will want to modify their applications to make use of Local Machine Zone Lockdown.

  • Developers will need to register their applications to take advantage of the changes. By default, Local Machine Zone Lockdown is only enabled for Internet Explorer. Applications that do not use this mitigation should independently review their applications for Local Machine zone attack vectors.

  • Software developers with applications that host Internet Explorer should use this feature by adding their process name to the registry as described later in this document. In the future, Microsoft might implement this feature using an “opt-out” policy rather than an “opt-in” policy. Applications that host Internet Explorer should be tested to ensure that they function properly with Local Machine Zone Lockdown enabled for their process.

  • Network administrators might have local scripts that will be affected by these restrictions. Administrators should review the available solutions to enable their local scripts without compromising the security of their user's client computers.

  • Developers of Web sites that are hosted on the Internet or Local Intranet zones should not be affected by changes to the Local Machine zone.

  • Users could be impacted by applications that are not compatible with these more stringent restrictions.

Feature Details

With Windows XP Service Pack 2, Local Machine Zone Lockdown will be even more restrictive than the Internet zone. Any time that content attempts one of these actions, the Information Bar will appear in Internet Explorer with the following text:

To help protect your security, Internet Explorer has restricted this file from showing active content that could access your computer. Click here for options...

The user can click the Information Bar to remove the lockdown from the restricted content.

The security settings that control the privileges that are granted to content running in the Local Machine zone are known as URL actions. When Local Machine Zone Lockdown is applied to a given process, it changes the behavior of URL actions from Allow to Disallow. As a result, scripts and Active X controls will not run. The URL actions are:

  • URLACTION_RUN_SCRIPT

  • URLACTION_DOWNLOAD_UNSIGNED_ACTIVEX

  • URLACTION_ACTIVEX_RUN

  • URLACTION_ACTIVEX_OVERRIDE_OBJECT_SAFETY

  • URLACTION_CLIENT_CERT_PROMPT

  • URLACTION_BEHAVIOR_RUN

  • URLACTION_JAVA_PERMISSIONS

For Local Machine Zone Lockdown, these settings are stored under a separate registry key:

HKCU\Software\Microsoft\Windows\CurrentVersion\
Internet Settings\Lockdown_Zones\0

The default Local Machine zone URL action settings are found under the following registry key:

HKCU\Software\Microsoft\Windows\
CurrentVersion\Internet Settings\Zones\0

Feature Impact

This change helps prevent content on a user’s computer from elevating privilege. Code with such elevated privilege can then run any code through an ActiveX control or read information with a script. If a Web page uses any of the restricted types of content that were previously listed, Internet Explorer displays the Information Bar, as previously described.

HTML files that are hosted on the res: protocol on the local computer will automatically run under the security settings for the Internet zone. For more information about what these templates allow, see “Introduction to URL Security Zones” on the MSDN Web site at http://go.microsoft.com/fwlink/?LinkId=26003.

If your Web page needs to run ActiveX or scripting, you can add a Mark of the Web comment in the HTML code. This Internet Explorer feature allows the HTML files to be forced into a zone other than the Local Machine zone so that they can then run the script or ActiveX code with a specified security template. This setting works in Internet Explorer 4 and later.

To insert a Mark of the Web comment into your HTML file, add one of the following comments:


<!-- saved from url=(0022)http://www.yoururl.com --> 

Use this comment when you are inserting a Mark of the Web into a page whose domain is identified, replacing http://www.yoururl.com with the URL of the Internet or intranet domain that the page is hosted by. Include the length of the URL in parenthesis used for the Mark of the Web before the URL (0022).


<!-- saved from url=(0013)about:internet -->

Use this comment when you need to generically insert a Mark of the Web. About:internet will place the page in the Internet zone.

As part of the changes to Internet Explorer in Windows XP Service Pack 2, this HTML comment can also be used with .mht files, known as multipart HTML. Mark of the Web will not be respected for .mht files in earlier versions of Internet Explorer.

As another option, you can create a separate application that hosts the HTML content in the Internet Explorer Web Object Control (WebOC). The HTML is then no longer bound by the same rules that apply to content that runs in Internet Explorer. When the HTML content runs in the other process, it can have full rights as defined by the developer or the zone policy for that process.

An easy way to do this is to save your content as an .hta (HTML application) file and try to run the file again in the Local Machine zone. An .hta file is hosted in a different process and therefore is not impacted by the mitigation. However, .hta files run with full privileges, so you should not allow code that is not trusted to run in this manner.

MIME Handling Enforcement

Feature Goal

Internet Explorer uses MIME-type information to decide how to handle files that have been sent by a Web server. For example, when there is an HTTP request for .jpg files, when they are received, they will generally be displayed to the user in an Internet Explorer window. If Internet Explorer receives an executable file, Internet Explorer generally prompts the user for a decision about how to handle the file.

In Windows XP Service Pack 2, Internet Explorer will follow stricter rules that are designed to reduce the attack surface for spoofing the Internet Explorer MIME-handling logic.

This feature applies to the following audiences:

  • Web developers need to be aware of these new restrictions to plan changes or workarounds for any possible impact to their Web site.

  • Application developers should review this feature to plan to adopt changes in their applications. The feature is not enabled for non–Internet Explorer processes by default, and developers will need to register their applications to take advantage of the changes.

  • End users will be impacted by sites that are not compatible with these stricter rules.

Feature Details

MIME-Handling File-Type Agreement Enforcement

When files are served to the client, Internet Explorer uses the following pieces of information to decide how to handle the file:

  • Filename extension and the corresponding ProgID for the registered handler of that file name extension

  • Content-Type from the HTTP header (MIME type) and the corresponding ProgID for the registered handler of that Content or MIME type

  • Content-Disposition from the HTTP header

  • Results of the MIME sniff

In Windows XP Service Pack 2, Internet Explorer is more restrictive about executing a downloaded file that could be dangerous. Internet Explorer requires that all file-type information that is provided by Web servers is consistent.

Internet Explorer will enforce consistency between how a file is handled in the browser and how it is handled in the Windows Shell. Using the pieces of data listed above, Internet Explorer will compare the ProgID of the registered MIME handler to the ProgID of the application that would handle the file association. If there is a mismatch between the ProgIDs, Internet Explorer will attempt to load the file in the registered MIME handler, but it will not execute the file if the MIME handler fails to load the file.

Also, if the MIME type of a file is “text/plain” but the MIME sniff indicates that the file is really an HTML, media, or executable file, Internet Explorer will not increase the privilege of the file compared with the server’s declared MIME type. In a MIME sniff, Internet Explorer examines, or sniffs, a file to recognize the bit signatures of certain types of files. If an incorrectly configured Web server hosts HTML files but sends text/plain as the Content-Type in the HTTP header, Internet Explorer will show the file as plain text, rather than rendering the HTML. Users may also experience this problem with multimedia, executable, and other files of high privilege hosted with an incorrect Content-Type header.

This change does not affect cases in which a “content-disposition=attachment” HTTP header is used for the file. In those cases, the filename or extension suggested by the server is considered final and is not changed based on MIME sniffing.

If file-type information is misreported by the server and that information is saved to the computer, a dangerous file could be handled incorrectly later. For example, in the above example, Internet Explorer might download a file, assuming it is a text file. If the file has the .exe file name extension, the file might run later with elevated privileges without prompting the user. Internet Explorer now renames files in the Internet Explorer cache to have matching content type and file extensions to enforce consistent handling of the file. This protects against files that mislead the user about their type. Additionally, Internet explorer will no longer execute files that are rejected by the registered mime-handler or any file that wasn’t successfully renamed to match extension to mime-type.

MIME Sniffing File-Type Elevation

One of the backup criteria for determining a file type is the result of the MIME sniff. By examining (or sniffing) a file, Internet Explorer can recognize the bit signatures of certain types of files. In Windows XP Service Pack 2, Internet Explorer MIME sniffing will never promote a file of “text/plain” type to a more dangerous file type in the Restricted Sites zone. For example, files that are received as plain text but that include HTML code will not be promoted to the HTML type, which could contain malicious active content.

In the absence of other file-type information, the MIME sniff might be the only information that determines how to handle a given file download. If, for instance, Internet Explorer upgrades a text file to an HTML file, the file might execute code from the browser and possibly elevate the file’s security privilege. This change provides users additional defense in depth against malicious content posted on a friendly web server with “content-type=text/plain” where an attacker has loaded html with active content into the file.

Web servers that do not include the correct Content-Type header with their files and that use nonstandard filename extensions for HTML pages now may have their pages rendered as plain text rather than HTML. You should configure Web servers to use the correct Content-Type headers, or you can name the files with the appropriate filename extension for the application that should handle the file.

Setting Changes in Service Pack 2

Table 10 lists setting changes related to MIME Handling Enforcement.

Table 10. Setting changes related to MIME Handling Enforcement

Setting Name

Location

Previous Default Value (if applicable)

Default Value

Possible Values

IExplore.exe

Explorer.exe

HKCU{LM}\Software\
Microsoft\
Internet Explorer\
Main\FeatureControl\
FEATURE_MIME_HANDLING\

None

1

0 (off),

1 (on)

IExplore.exe

Explorer.exe

HKCU{LM}\Software\
Microsoft\
Internet Explorer\
Main\FeatureControl\
FEATURE_MIME_SNIFFING\

None

1

0 (off),

1 (on)

Table 11 lists the default MIME Handling Enforcement settings for each security zone.

Table 11. Default MIME Handling Enforcement settings

Security Zone

Open files based on content, not file extension

Restricted Sites Zone

Disable

Internet Zone

Enable

Intranet Zone

Enable

Trusted Sites Zone

Enable

Object Caching

Feature Goal

In previous versions of Windows with Internet Explorer, some Web pages could access objects cached from another Web site. In Windows XP Service Pack 2, a reference to an object is no longer accessible when the user navigates to a new domain.

This feature applies to the following audiences:

  • Web developers should review this feature and plan to adopt changes to their Web site.

  • Application developers should review this feature and plan to adopt changes in their applications.

Feature Details

For Windows XP Service Pack 2, there is now a new security context on all scriptable objects so that access to cached objects except for ActiveX controls are blocked. In addition to blocking access when navigating across domains, access is also blocked when navigating within the same domain. (In this context, a domain is defined as a fully qualified domain name, or FQDN.) A reference to an object is no longer accessible after the context has changed due to navigation.

Before Internet Explorer 5.5, navigations across HTML pages (or to sub-frames) purged instances of MSHTML, which is the Microsoft HTML parsing and rendering engine. With the Internet Explorer 5.5 Native Frames architecture, an instance of MSHTML lives across navigations. This introduced a new class of vulnerabilities because objects could be cached across navigations. If an object can be cached and provide access to the contents of a Web page from another domain, there is a cross-domain hole.

Once you can get to properties on the inner document, script outside of a page’s domain can access the contents of an inner page. This is a violation of the Internet Explorer cross-domain security model.

For example, you can use this method to create scripts that listen to events or content in another frame, such as credit card numbers or other sensitive data that is typed in the other frame.

Feature Impact

In those few classes that don’t already have them, four more bytes are added for the cached markup. There should be no noticeable impact on speed. For most of these classes of vulnerabilities, Internet Explorer 5 would have crashed, so the application-compatibility risk of fixing the exploit should be small. Other applications might need to be addressed on a case by case basis.

Setting Changes in Service Pack 2

Table 12 lists setting changes related to object caching.

Table 12. Setting changes related to object caching

Setting Name

Location

Previous Default Value (if applicable)

Default Value

Possible Values

IExplore.exe

Explorer.exe

HKCU{LM}\Software\
Microsoft \
Internet Explorer\
Main\
FeatureControl \
FEATURE_OBJECT_CACHING

None

1

0 (Off)

1 (On)

Pop-up Blocker

Feature Goal

Pop-up Blocker blocks most unwanted pop-up windows from appearing. Pop-up windows that are opened when the end user clicks a link will not be blocked.

End users and IT administrators can let specific domains open programmatic pop-up windows. Developers will be able to use or extend the pop-up functionality in Internet Explorer for applications hosting Internet Explorer.

This feature applies to the following audiences:

  • For end users, browsing the Web will be less annoying because unwanted pop-up windows will not automatically appear.

  • For Web developers, Pop-up Blocker affects the behavior of windows opened by Web sites, for example, by using the window.open() and showHelp() methods.

  • For application developers, there is a new user interface called InewWindowManager.

  • Applications that use the rendering engine in Internet Explorer to display HTML can choose to use or extend the Pop-up Blocker functionality.

Feature Details

The Pop-up Blocker is a new feature for Internet Explorer that can be broken down into three sections:

  • Pop-up Blocker general features—user experience changes, defaults, and advanced options.

  • Changes in behavior of current APIs, such as window.open and showHelp.

  • The new INewWindowManager interface, which allows applications to use the pop-up technology in Internet Explorer.

Pop-up Blocker General Features

Pop-up Blocker is turned on by default. There are restrictions on the size and position of pop-up windows, regardless of the Pop-up Blocker setting: Pop-up windows cannot be opened larger than or outside the viewable desktop area. For more information, see the section “Window Restrictions” in this document.

When this functionality is enabled, automatic and background pop-up windows are blocked, but windows that are opened by a user click will still open in the usual manner. Note that sites in the Trusted Sites and Local Intranet zones never have their pop-up windows blocked, as they are considered safe. This can be configured in the Security tab in Internet Options.

Enabling Pop-up Blocker

You can enable Pop-up Blocker by three different methods:

  • A prompt that appears before the first pop-up window asks the customer to enable Pop-up Blocker.

  • In Internet Explorer, on the Tools menu, click Pop-up Blocker, and then click Block Pop-up Windows.

  • In Internet Explorer, on the Tools menu, click Internet Options, click the Privacy tab, and then click Block Pop-up Windows. You can then click Options to configure Pop-up Blocker settings.

When a Pop-up Window Is Blocked

If a site opens a pop-up window that is blocked by Internet Explorer, a notification appears in the status bar and a sound is played. If you click the notification in the status bar, you see a menu with the following options:

  • Show Blocked Pop-up Window. Reloads the pop-up window.

  • Allow Pop-up Windows from This Site. Adds the current site to the Allow list.

  • Block Pop-up Windows. Toggles Pop-up Blocker on and off.

  • Pop-up Window Options. Opens the Pop-up Window Management window.

Advanced Options

Internet Explorer provides advanced configuration of Pop-up Blocker settings.

  • Web Site Allow List. You can add sites to the Allow list. Any site on the Allow list can open pop-up windows.

  • Block All Pop-up Windows. Pop-up Blocker allows sites to open a pop-up window when the user clicks a link. This setting changes that behavior by blocking windows that are opened from a link. If this setting is enabled, you can allow pop-up windows to open by pressing ALT at the same time that you click the link.

  • Override Key. When Block All Pop-up Windows is enabled, you can allow pop-up windows to open by pressing ALT at the same time that you click the link.

  • Configure Sound. You can toggle whether or not Pop-up Blocker plays a sound when a pop-up is blocked through the Advanced settings in Internet Options. You can also change the sound that plays. To do this, click Start, click Control Panel, and then double-click the Sounds and Audio Devices icon.

  • Zones. Customers can expand the scope of Pop-up Blocker to include the Local Intranet or Trusted Sites zones in the Security tab of Internet Options.

When Will End Users See Pop-up Windows While Pop-up Blocker Is Enabled?

Customers will still see pop-ups windows opened in the following cases:

  • The pop-up is opened by a link which the user clicked.

  • The pop-up is opened by software that is running on the computer.

  • The pop-up is opened by ActiveX controls that are instantiated from a Web site.

  • The pop-up is opened from the Trusted Sites or Local Intranet zones.

INewWindowManager

By default, the Pop-up Blocker functionality does not apply to applications that host the WebBrowser control or MSHTML. These applications have the ability to use or extend Pop-up Blocker, use their own pop-up manager, or disable pop-up management for their application through the INewWindowManager interface.

window.open(), window.external.navigateAndFind(), showHelp()

In the Internet zone, the Pop-up Blocker blocks windows that are automatically opened by these methods without the user clicking a link. Windows that are opened by these methods by clicking a link might also be blocked if the customer has enabled the more restrictive blocking setting.

If a function normally returns a window object, then the function will return null when a window is blocked. Web developers can check for null to determine whether the window they attempted to open was blocked.

Windows that are outside the viewable screen when they are opened are positioned onto the viewable area. Windows that are larger than the viewable screen when they are opened are resized to the viewable area.

Setting Changes in Service Pack 2

Table 13 list setting changes related to the Pop-up Blocker.

Table 13. Setting changes related to the Pop-up Blocker

Setting Name

Location

Previous Default Value (if applicable)

Default Value

Possible Values

URLname

HKCU\Software \
Microsoft\
Internet Explorer\
New Windows\Allow

None

Empty

URL names of trusted sites

Untrusted Publishers Mitigations

Feature Goal

This feature allows the user to block all signed content from a given publisher without showing the Authenticode dialog box to the user while doing so. This stops code from the blocked publisher to be installed. This feature also blocks installation of code with invalid signatures.

This feature applies to all users, since it deals with installation and running of applications that are signed.

Feature Details

Blocked Publisher

Through Authenticode, the user can block content for a given publisher from installing or running. To do this, the user selects the Never trust content from Publisher Name check box in the Authenticode dialog box. If selected, the user is never prompted when code that is identified with the publisher’s digital signature is trying to install itself on his or her system. It will be automatically blocked without showing the Authenticode dialog box.

This feature was designed to help users block ActiveX controls and other signed file formats from repeatedly prompting them on the Web. Users had no way of saying, “I don’t want content from this publisher. Do not ask me again.” Because they didn’t have this feature, many users installed applications or content just to keep from encountering repeated prompts.

Previously, the Authenticode dialog box only supported selecting the Always trust content from Publisher check box, which allowed the automatic install of code from a specified publisher without prompting the user. Now the user can perform the opposite action and designate a publisher as untrusted. No application-compatibility issues should be encountered for trusted code.

Blocking Invalid Signatures

By default, Windows blocks the installation of signed code if it has an invalid digital signature. If code has an invalid signature, it usually means that the code has been changed since it was signed. When this happens, Internet Explorer considers the code to be unsigned, since someone might have tampered with it. By default, Internet Explorer blocks ActiveX applications that are unsigned that come from the Internet zone. This extends that functionality so that it applies to all code with invalid signatures.

One Prompt Per Control Per Page

Internet Explorer only prompts once per ActiveX control per page. It mitigates the social engineering trick of prompting the user a number of times for the same control. Even though users repeatedly refuse, they cannot get out of the loop, and they might eventually accept the installation out of frustration.

Ellipsis Placed on Text for Application Description and Publisher Name

When the text that is given for the application description, filename, or publisher name is wider than the dialog box in width, Internet Explorer places an ellipsis on the text. This helps indicate to the user that there is more text that he or she is not seeing.

This reduces the ability of control authors from placing marketing text and EULAs in the dialog box or using other social engineering tricks to overwhelm the users and get them to install the control.

Application description, filenames, and publisher names will contain an ellipsis if the text is longer than the width of the dialog box. No applications or Web pages should need to be modified.

Setting Changes in Service Pack 2

Table 14 lists setting changes related to untrusted publishers mitigations.

Table 14. Setting changes related to untrusted publishers mitigations

Setting Name

Location

Previous Default Value (if applicable)

Default Value

Possible Values

RunInvalidSignatures

HKCU{LM}\Software \
Microsoft \
Internet Explorer\
Download

None

0

1

Window Restrictions

Feature Goal

Internet Explorer provides the capability for scripts to programmatically open additional windows of various types and to resize and reposition existing windows. The Window Restrictions security feature, formerly called UI Spoofing Mitigation, restricts two types of script-initiated windows that have been used by malicious persons to deceive users: pop-up windows (which do not have components such as the address bar, title bar, status bar, and toolbars) and windows that include the title bar and status bar.

This feature applies to the following audiences:

  • Web developers should be aware of these new restrictions to plan changes or workarounds for any possible impact to their Web site.

  • Application developers should review this feature to plan to adopt changes in their applications. This feature is only enabled by default for Internet Explorer processes. Developers must register non–Internet Explorer applications to take advantage of the changes.

Feature Details

Script Repositioning of Internet Explorer Windows

Script-initiated windows with the title bar and status bar are constrained in scripted movement to ensure that these important and informative bars remain visible after the operation completes.

  • Scripts cannot position windows so that the title bar or address bar are above the visible top of the display.

  • Scripts cannot position windows such that the status bar is below the visible bottom of the display.

Without this change, windows that are created by the window.open() method can be called by scripts and spoof a user interface or desktop or hide malicious information or activity by one of the three following methods:

  • Positioning the window such that the title bar, status bar, or address bar are offscreen.

  • Positioning the window to hide important elements of the user interface from the user.

  • Positioning the window so that it is entirely offscreen.

The visible security features of Internet Explorer windows provide information to the user to help them ascertain the source of the Web page and the security of the communication that uses that page. When these elements are hidden from view, users might think they are on a more trusted page or interacting with a system process when they are actually interfacing with a malicious host. Malicious use of window relocation can present false information to the user, obscure important information, or otherwise “spoof” important elements of the user interface in an attempt to motivate the user to take unsafe actions or to divulge sensitive information.

This change places constraints on positioning of script-initiated windows with a title bar and status bar to ensure that the title bar and status bar in these windows are always visible to the user. Scripts cannot move a window offscreen, although the user can still move a window offscreen. If you maintain a script that creates offscreen windows in Internet Explorer, you need to change your code. If your script creates or moves a window offscreen, you should examine this requirement and choose another way to accomplish your goal. You cannot bypass or disable this security feature.

Script Sizing of Internet Explorer Windows

Script-initiated windows that include a title bar and status bar are constrained in scripted sizing to ensure that the title bar and status bar remain visible after the operation completes.

  • Scripts cannot resize windows such that the title bar, address bar, or status bar cannot be seen.

  • When creating a window, the definition of the fullscreen=yes specification is changed to mean “show the window as maximized,” which will keep the title bar, address bar, and status bar visible.

Without this change, windows that are created using the window.open() method can be called by scripts and spoof a user interface or desktop or hide malicious information or activity by sizing the window so that the status bar is not visible.

With this change, there are constraints on sizing of script-initiated windows to ensure that the title bar and status bar of these windows is always visible to the user. The result is that a script cannot open a window in kiosk mode, a mode that does not display the title bar, address bar, and status bar, which present important security information to the user.

The user can choose to display a window in kiosk mode. This election is still persistent. Script-initiated windows will be displayed fully, with the Internet Explorer title bar and status bar. The user or the site administrator can manually change this state.

Script Management of Internet Explorer Status Bar

Internet Explorer has been modified to not turn off the status bar for any windows. The status bar is always visible for all Internet Explorer windows.

Without this change, windows that are created using the window.open() method can be called by scripts and spoof a user interface or desktop or hide malicious information or activity by hiding important elements of the user interface from the user.

The status bar is a security feature of Internet Explorer windows that provides Internet Explorer security zone information to the user. This zone cannot be spoofed and lets the user know exactly what security zone the displayed content is in. When the status bar is hidden from view, users might think they are on a more trusted page when they are actually interacting with a malicious host.

Internet Explorer Pop-up Window Placement

Script-initiated pop-up windows are now constrained so that they:

  • Do not extend above the top or below the bottom of the parent Internet Explorer Web Object Control (WebOC) window

  • Are smaller in height than the parent WebOC window

  • Overlap the parent window horizontally

  • Stay with the parent window if the parent window moves

  • Appear above its parent so that other windows (such as a dialog box) cannot be hidden

Pop-up windows are created by the window.createPopup() method and also called chromeless windows because they do not have the border “chrome” components, such as the address bar, title bar, status bar, and toolbars. These windows:

  • Can be opened on top of a dialog box and obscure or replace important elements

  • Can be used to overlay the address bar with a different address

  • Can simulate a full-screen Windows desktop with a password dialog box

Unrestricted chromeless windows can deceive the user in several ways:

  • A chromeless pop-up window that is opened on top of a dialog box can obscure or replace important elements of the dialog box, such as warning text and selection or action controls. (These include check boxes, option buttons, and so on.) This might lead the user to a response that might be inappropriate or harmful.

  • A chromeless pop-up window can overlay the address bar with an address that is different from the actual address of the page, which gives the user a false sense of security. In the same way, it can overlay the status notification area, so it might indicate that Internet Explorer is displaying a secure Web page (which displays a URL beginning with https://). Because of this, the user might think that security is in effect for the page when no such security exists.

  • A chromeless pop-up can use the entire display. With this method, a malicious user can simulate a full-screen Windows desktop with a password dialog box, with a malicious script that captures the user’s private authentication information.

Pop-up windows are constrained horizontally, vertically, and in order of placement on top of other windows.

  • A pop-up window must appear between the top and bottom of its parent window’s chrome, so it does not overlap the Internet Explorer address bar, title bar, status bar, or toolbars.

  • Horizontally, a pop-up window must always overlap some area of its parent window.

  • A pop-up window must stay immediately on top of its parent, so it cannot be placed over other windows.

These constraints might affect the appearance of a pop-up window if it has been designed to display in an area that is larger or separate from its parent window. The pop-up windows will be truncated, which might obscure some of the information displayed on that window.

Setting Changes in Service Pack 2

There is only one setting for this feature, shown in Table 15. This setting enables the Window Restrictions (1) or does not enable them (0). For application compatibility, this feature is not enabled by default for non–Internet Explorer processes.

Table 15. Setting changes related to Window Restrictions

Setting Name

Location

Previous Default Value

Default Value

Possible Values

IExplore.exe

HKCU{LM}\Software\
Microsoft\
Internet Explorer\
Main\FeatureControl\
FEATURE_WINDOWS_RESTRICTIONS\

n/a

1

0 (off)

1(on)

Zone Elevation Blocks

Feature Goal

When a Web page is opened in Internet Explorer, Internet Explorer puts restrictions on what the page can do, based on where that Web page came from: the Internet, a local intranet server, a trusted site, and so on. For example, pages on the Internet have stricter security restrictions than pages on a user’s local intranet. Web pages on a user’s computer are in the Local Machine security zone, where they have the fewest security restrictions. This makes the Local Machine security zone a prime target for malicious users. Zone Elevation Blocks makes it harder to get code to run in this zone. In addition, Local Machine Zone Lockdown makes the zone less vulnerable to malicious users by changing its security settings.

This feature applies to the following audiences:

  • Web developers must plan changes or workarounds for any possible impact to their Web site.

  • Application developers should review this feature to plan to adopt changes in their applications that run in the Local Machine security zone. Since the feature is not enabled for processes other than Internet Explorer by default, developers must register their applications to take advantage of the changes.

  • End users might be impacted by sites that are not compatible with these stricter rules and settings.

Feature Details

Internet Explorer prevents the overall security context for any link on a page from being higher than the security context of the root URL. This means, for example, that a page in the Internet zone cannot navigate to a page in the Local Intranet zone. A script, for example, could not cause this navigation. For the purpose of this mitigation, the security context ranking of the zones, from highest security context to lowest, is Restricted Sites zone, Internet zone, Local Intranet zone, Trusted Sites zone, and Local Machine zone.

Zone Elevation Blocks also disables JavaScript navigation if there is no security context.

Elevation of privilege is one of the most exploited vulnerabilities in Internet Explorer, with the ultimate goal of running malicious code in the Local Machine zone. Zone Elevation Blocks helps mitigate many privilege escalation attacks.

Navigation from one zone to a “higher” zone is blocked. This means that Web pages that automatically call more privileged Web pages fail. If a trusted Web application cannot be used, you can modify the Internet Explorer security zone settings to allow the application to continue working.

Network Protocol Lockdown

Feature Goal

In Windows XP Service Pack 2, Internet Explorer can be configured to lock down HTML content from particular network protocols in additional zones besides the Local Machine Zone. This feature allows an admin to extend the same restrictions of the Local Machine Zone Lockdown (previously described in the document) to be applied to any content on any arbitrary protocol in any security zone. For example, an administrator can configure Internet Explorer to lock down HTML content hosted on the Shell: protocol if it is in the Internet zone. Since the Shell: protocol’s most common use is for local content not Internet content, this mitigation can reduce the attack surface of the browser against possible vulnerabilities in protocols less commonly used than HTTP.

By default, Network Protocol Lockdown is not enabled for any application.

This feature applies to the following audiences:

  • All application developers should review this feature. Applications that host HTML files over non-HTTP protocols in Internet Explorer might be impacted in organizations in which administrators elect to apply additional restrictions. Developers of standalone applications that host Internet Explorer might want to modify their applications to make use of Network Protocol Lockdown.

  • Developers who chose to opt-in should to register their applications to take advantage of the changes. Developers that do not use this mitigation should independently review their applications for support for arbitrary protocols.

  • Software developers with applications that host Internet Explorer can use this feature by adding their process name to the registry as described later in this document. In the future, Microsoft might implement this feature with certain uncommonly used protocols restricted by default and with an opt-out policy for applications rather than the current opt-in policy for applications. Applications that host Internet Explorer should be tested to ensure that they function properly with Network Protocol Lockdown enabled for their process.

  • Network administrators should consider adding unused protocols to the restricted protocol list on managed desktop machines. If the network admin enables this restriction, he or she might have HTML files that will be affected.

  • Developers of Web sites that are hosted on the http: protocol should not be affected by restrictions to other protocols.

  • Users are most likely to be impacted by these more stringent restrictions if their network administrator chose to restrict certain protocols for their desktop.

Feature Details

With Windows XP Service Pack 2, HTML content in an opt-in application that is served on one of the restricted protocols will be restricted to run at a higher security level. Any time the restricted protocol content attempts to use a restricted feature, such as ActiveX controls, the Information Bar will appear in Internet Explorer with the following text:

The webpage is trying to communicate in a way that maybe unsafe. Click here for more options.

The user can click the Information Bar to remove the lockdown from the restricted content.

The security settings that are locked down for the content on the restricted protocols are the same as the settings enforced for the Local Machine Zone lockdown which is described earlier in this document. Please consult that section to review exactly which security settings are enforced for the content on the restricted protocols.

Restricted Protocols Feature Is OFF by Default for Internet Explorer and All Applications

The behavior of the Network Protocol Lockdown is controlled per process by a new Internet Explorer Feature Control setting. Since this feature is designed to provide an additional layer of defense-in-depth for network administrators, the default Internet Explorer processes, IExplore.exe and Explorer.exe are NOT opted in by default. To opt in to the Network Protocol Lockdown, network administrators or developers should add a DWORD value at this location where the value name is their process name and the value is set to 1 to have the mitigation apply to them, set to 0 to forcibly opt out. Application developers may want to proactively opt out to prevent the mitigation from being applied to them when a wildcard is used to force the mitigation into opt-out mode.

HKCU{LM}\Software\(Policies)\Microsoft\Internet Explorer\
Main\FeatureControl\FEATURE_PROTOCOL_LOCKDOWN

Behavior Per-Zone When an Application Has “Opted-In”

For an “opted-in” process, the behavior of the Network Protocol Lockdown is also controlled per zone by a new Internet Explorer security setting or URLAction. This URLAction will be set to following values, as Table 16 shows.

Table 16. Setting changes related to Network Protocol Lockdown

Security Zone

Default Behavior for Restricted Protocols

Example of What the User Might See

Restricted Sites Zone

Prompt

Since ActiveX is never allowed in the Restricted sites zone by default, no information bar would be shown.

Internet Zone

Prompt

If the admin black-lists the file:// protocol, HTML that uses script over the file:// protocol would be restricted but users could click on the Information bar to allow it.

Intranet Zone

Prompt

If the admin black-lists the local:// protocol, HTML that uses Java over the local:// protocol would be restricted but users could click on the Information bar to allow it.

Trusted Sites Zone

Prompt

If the admin black-lists the Shell:// protocol, HTML that uses Binary Behaviors over the Shell:// protocol would be restricted but users could click on the Information bar to allow it.

Local Machine Zone

Not Applicable—By default, the Local Machine Zone Lockdown feature already restricts all HTML, independent of protocol.

Not Applicable—By default, the Local Machine Zone Lockdown feature already restricts all HTML, independent of protocol.

Per-Zone Protocol Blacklists

The list of protocols that are restricted is defined separately for each zone to allow some protocols to be locked down in some zones but run without restrictions in other zones. Protocols can be restricted for a given zone by writing the protocol name to the restricted list for a particular security zone. Zones are listed in Table 17.

Table 17. Setting per-zone protocol blacklists

Security Zone

Registry Location of the List of

Restricted Protocols for Each Zone

Security Settings Applied to Restricted Protocol Content

Restricted Sites Zone

HKCU{LM}\Software\(Policies)\
Microsoft\Windows\
CurrentVersion\Internet Settings\
RestrictedProtocols\4

HKCU\Software\Microsoft\
Windows\CurrentVersion\
Internet Settings\
Lockdown_Zones\4

Internet Zone

HKCU{LM}\Software\(Policies)
\Microsoft\Windows\
CurrentVersion\Internet Settings\
RestrictedProtocols\3

HKCU\Software\Microsoft\
Windows\CurrentVersion\
Internet Settings\
Lockdown_Zones\3

Intranet Zone

HKCU{LM}\Software\(Policies)\
Microsoft\Windows\
CurrentVersion\Internet Settings\
RestrictedProtocols\2

HKCU\Software\Microsoft\
Windows\CurrentVersion\
Internet Settings\
Lockdown_Zones\2

Trusted Sites Zone

HKCU{LM}\Software\(Policies)\
Microsoft\Windows\
CurrentVersion\Internet Settings\
RestrictedProtocols\1

HKCU\Software\Microsoft\
Windows\CurrentVersion\
Internet Settings\
Lockdown_Zones\1

Local Machine Zone

Not Applicable—By default, the Local Machine Zone Lockdown feature already restricts all html, independent of protocol.

Not Applicable—By default, the Local Machine Zone Lockdown feature already restricts all html, independent of protocol.

Protocols to Consider for Black-Listing

The default list of restricted protocols is blank. Network administrators should add additional protocols to the lockdown that they know are not needed in their organization for a particular zone. Network administrators should consider restricting some of the following default Windows protocols on managed desktop machines and other protocols that are not needed for rendering HTML with active content in the administrator’s organization.

  • Local://

  • File://

  • Shell://

  • hcp://

  • ftp://

Feature Impact

This change provides general defense in depth against vulnerabilities in less-frequently-used protocols. For example, an ActiveX control run via the Local:// protocol might assume that it is loaded in the Local Machine Zone and it may grant elevated privilege to the hosting page.

If a Web page served on a protocol that is restricted for a given zone uses any restricted content, such as ActiveX, Internet Explorer will display the Information Bar, as previously described. If your Web page needs to run ActiveX or scripting on a protocol that should be restricted for your intranet, you might allow the HTML to render correctly by moving the domain for that HTML to the trusted sites zone on the managed desktop machines. As a long-term solution, you might look for ways to move the content off of the restricted protocol or if that’s not possible, you might remove the active content from the restricted protocol pages entirely by performing needed computations on the server using a server-side script such as Active Server Pages.

New Group Policy Settings Affecting Internet Explorer

Windows XP Service Pack 2 introduces new registry keys and values for Internet Explorer security features called Feature Control. A modified Inetres.adm file contains new feature control settings as policies. Administrators can manage the new feature control policies by using Group Policy Objects (GPOs). When Internet Explorer is installed, the default HKLM preferences settings for these feature controls are registered on the computer. In Group Policy, the Administrator can set them in either HKLM (Computer Configuration) or HKCU (User Configuration). Group Policy administrators can uniformly configure the new Internet Explorer Feature Control settings for the computers and users that they manage.

The following new feature control policies are available:

  • Binary Behavior Security Restriction

  • MK Protocol Security Restriction

  • Local Machine Zone Lockdown Security

  • Consistent MIME Handling

  • MIME Sniffing Safety Feature

  • Object Caching Protection

  • Scripted Window Security Restrictions

  • Protection from Zone Elevation

  • Information Bar

  • Restrict ActiveX Install

  • Restrict FileDownload

  • Add-on Management

  • Network Protocol Lockdown

Administrators of Group Policy can manage these new policies in the Administrative Templates extension to the Group Policy console. When configuring these policies, the administrator can enable or disable the security feature for explorer processes (Internet Explorer and Windows Explorer), for executable processes that they defined, or for all processes that host the WebOC.

Users cannot see the feature control policies or preference settings through the Internet Explorer user interface, except for Local Machine Zone Lockdown Security. Feature control policies can only be set using the Group Policy console, and feature control preference settings can only be changed programmatically or by editing the registry.

Group Policy is the recommended tool for managing Internet Explorer for client computers on a corporate network. Internet Explorer supports Group Policy management for all new functionality in Windows XP Service Pack 2.  For more information about Group Policy settings for Internet Explorer in Windows XP Service Pack 2, see “Managing Windows XP Service Pack 2 with Group Policy” on the Microsoft web site at http://go.microsoft.com/fwlink/?LinkId=31974.

Internet Explorer Administration Kit (IEAK) 6 Service Pack 1 is the recommended tool for solution providers and application developers to customize Internet Explorer for their end users. (For more information, see “Microsoft Internet Explorer 6 Administration Kit Service Pack 1” on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=26002.) Custom packages that are generated from IEAK 6 Service Pack 1 will transparently apply settings to Internet Explorer running on Windows XP Service Pack 2 but will not install any binaries. IEAK 6 Service Pack 1 is not supported for corporate desktop management.

Note: Internet Explorer settings made by Group Policy always override settings implemented using the IEAK.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft