Event 1037 - Protected Mode
Applies To: Windows 7, Windows Vista
Protected Mode reduces the severity of threats to both Windows® Internet Explorer® and extensions running in Internet Explorer, by eliminating the ability to install malicious code silently through software vulnerabilities. Protected Mode takes advantage of the User Interface Privilege Isolation (UIPI) to block Internet Explorer from interacting with system resources associated with higher integrity applications.
For additional Protected Mode information, see Understanding and Working in Protected Mode Internet Explorer and the Event 1037-Protected Mode topic from Internet Explorer Application Compatibility.
What is Protected Mode?
Protected Mode is an important step forward in security for Internet Explorer. It can help protect users from attack, by running an Internet Explorer process with greatly restricted privileges on the Windows Vista® or newer operating systems. While Protected Mode does not protect against all forms of attack, it significantly reduces the ability of an attack to write, to alter, or to destroy data on the user's machine, or to install malicious code.
While most Internet Explorer security features will be available in Internet Explorer for the Windows XP operating systems, Protected Mode is only available on Windows Vista or newer operating systems, because it is based on security features that were new to Windows Vista.
Understanding the Integrity Mechanism
The Windows operating system uses integrity-level labels for processes and other securable objects, an addition to the access-control security mechanism of Windows. The integrity level defines which network-enabled programs are at higher risk for exploitation because they download untrustworthy content from unknown sources. Running these at-risk programs with more restricted permissions or at a lower integrity level than other programs reduces the ability of malicious code to modify the system or harm user data files.
Protected Mode uses the Windows Vista integrity mechanism to run the Internet Explorer process at Low integrity level. The main features of the integrity level mechanism are as follows:
Securable objects, like files and registry keys, have security descriptors that define the integrity level, or level of privilege required for write access to the object. This integrity level is defined with a new mandatory access-control entry (ACE) in the system access-control list (SACL) called a mandatory label. Objects without mandatory labels have an implied default integrity level of Medium.
Processes have an integrity level defined in the security access token. In Protected Mode, Internet Explorer has a Low integrity level, applications started from the Start menu have a Medium integrity level, and applications that require Administrator permissions run with a High integrity level.
Low integrity processes cannot gain write access to objects at a higher integrity level, even if the user's SID has write access in the discretionary access-control list (DACL). The Windows operating system performs the integrity-level checks before user access permission checks.
All files and registry keys in the Windows operating systems after Windows Vista have a default integrity level of Medium. A Low integrity process, like Internet Explorer in Protected Mode, will receive access denied errors when it tries to modify existing files.
Some folders have a Low integrity mandatory label. A Low integrity level process can create and modify files in Low integrity folders. For example, the Temporary Internet Files folder contains a folder called Low, which is a Low integrity folder. Additionally, the integrity mechanism automatically assigns Low integrity mandatory labels to securable objects, files, or other objects created by Low integrity-level processes. By default, child processes started by a Low integrity process will also run with a Low integrity level.
The following table shows supported integrity access levels and the privileges they confer.
|Integrity Access Level (IL)||System Privileges|
Administrative. The process can install files to the Program Files folder and write to sensitive registry areas such as
User. The process can create and modify files in the user's Documents folder and write to user-specific areas of the registry, such as
Not Trusted. The process can only write to Low integrity locations, such as the Temporary Internet Files\Low folder or the
A user can configure Protected Mode, by using the Internet Explorer Internet Options dialog box.
To configure Protected Mode
From the Internet Options dialog box, click the Security tab.
Select the applicable Web content zone, and then select or clear the Enable Protected Mode (requires restarting Internet Explorer) check box.
Verify that your changes to Protected Mode were successful, by looking for the Protected Mode: On or Protected Mode: Off message that appears next to the Web content zone in the Internet Explorer status bar.
An Administrator can configure Protected Mode, by using Group Policy and the
URLACTION_LOWRIGHTS (0x00002500) URL Action Flags registry key. For more information, see URL Security Zones Overviews, located on MSDN.
Debugging by Using the Internet Explorer Compatibility Test Tool
You can use the Internet Explorer Compatibility Test Tool (IECTT), included with the Application Compatibility Toolkit, to debug Protected Mode issues. When Internet Explorer or its extensions attempt to write to securable objects in Protected Mode, IECTT generates an entry in the log file describing the operation and its results. The following list explains the possible values in the log entries:
ModuleName. The name of the file that started the process, which is attempting to access securable objects.
VirtualizationAction. Provides the results of the write operations, including one of the following values:
InterceptedWrite. Indicates that the Compatibility Layer intercepted the operation.
WriteIgnored. Indicates that Protected Mode ignored the operation because the attempting process is an elevated broker.
CreateVirtualCopy. Indicates that the Compatibility Layer made a copy of the object in a virtual location.
CreateNew. Indicates that the Compatibility Layer created a new object in a new location.
ObjectType. Specifies whether the object is a File or Registry setting.
APIName. Specifies the function attempting the flagged operation, for example CreateFile or RegOpenKey.
ReqObjectPath. Location of the object that the operation attempted to modify. This is blank for objects that do not have file paths.
NewObjectPath. Specifies the object that was to be modified by the operation, if the write operation had succeeded.
APIResult. Specifies the returned result from the API function that is attempting the write operation.
LastError. The last error received by an API function.