Protected Mode in Vista IE7
Hi, I’m Mike Friedman. I work on the IE team in the area of security. You may remember me from my previous IE blog post. We here on the IE team have a continuing focus on making web browsing safe from a variety of outside threats. Microsoft Windows Vista introduced an enhanced security model that we were able to build on in Vista's version of IE7. I want to tell you about a new major IE defense-in-depth security feature called Protected Mode. Defense in depth is a security principle that a system should provide multiple layers of defense, in case one layer is ever breached. Protected Mode takes advantage of three key new technologies in Vista's security model:
- User Account Control (UAC), which implements the Principle of Least Privilege.
UAC will help users run Vista without requiring administrator privileges to be productive. Administrators can also run most applications with a limited privilege, but have "elevation potential" for specific administrative tasks and application functions.
- Mandatory Integrity Control (MIC), a model in which data can be configured to prevent lower-integrity applications from accessing it. The primary integrity levels are Low, Medium, High, and System. Processes are assigned an integrity level in their access token. Securable objects such as files and registry keys have a new mandatory access control entry (ACE) in the System Access Control List (ACL).
- User Interface Privilege Isolation (UIPI) blocks lower-integrity from accessing higher-integrity processes. For example, a lower-integrity process cannot send window messages or hook or attach to higher priority processes This helps protect against "shatter attacks." A shatter attack is when one process tries to elevate privileges by injecting code into another process using windows messages.
Internet-facing applications such as browsers are inherently at a higher security risk than other applications because they can download untrustworthy content from unknown sources. IE7’s Protected Mode leverage's Windows Vista’s UAC, MIC and UIPI features to boost browser security. In IE7’s Protected Mode—which is the default in other than the Trusted security zone—the IE process runs with Low rights, even if the logged-in user is an administrator. Since add-ins to IE such as ActiveX controls and toolbars run within the IE process, those add-ins run Low as well. The idea behind Protected Mode IE is that even if an attacker somehow defeated every defense mechanism and gained control of the IE process and got it to run some arbitrary code, that code would be severely limited in what it could do. Almost all of the file system and registry would be off-limits to it for writing, reducing the ability of an exploit to modify the system or harm user files. The code wouldn't have enough privileges to install software, put files in the user's Startup folder, hijack browser settings, or other nastiness.
In Protected Mode IE writes/reads special Low versions of the cache, TEMP folder, Cookies and History:
- Cache: %userprofile%\AppData\Local\Microsoft\Windows\Temporary Internet Files\Low
- Temp: %userprofile%\AppData\Local\Temp\Low
- Cookies: %userprofile%\AppData\Roaming\Microsoft\Windows\Cookies\Low
- History: %userprofile%\AppData\Local\Microsoft\Windows\History\Low
When IE runs outside of Protected Mode (the default for the Trusted security zone), it does not cross the security boundary to read the Low versions. However, the Favorites folder is shared between the modes.
In a similar vein insulating higher integrity processes from lower integrity processes, Protected Mode leverages UIPI to block window messages to higher-integrity processes and other forms of lower-to-higher access, to guard against web-based shatter attacks.
Conforming to the security concept of “least privilege,” web browsing and other routine functionality takes place at Low integrity level. Protected Mode does occasionally need to have functions performed at Medium and High integrity levels. For this purpose, Protected Mode uses the security concept of “separation of privilege.” Medium level functions are carried out by a separate User Broker process. High level functions are carried out by a separate Admin Broker process. An example of a function requiring an admin's High rights is the installation of an ActiveX control or a “setup.exe” type of installation. The Admin Broker carries out the ActiveX installation on IE’s behalf. The Admin Broker always gains the user’s consent before acting. An example of a function requiring Medium rights is a SaveAs operation to the user’s user profile folder. Here the medium-level User Broker assists. For most operations the User Broker requires user consent.
Because Low rights is such as restrictive environment, Protected Mode includes compatibility features. These features allow most add-ins to run unaffected. Protected Mode provides a “compatibility layer” that consists of a set of shims that intercept certain system API calls. There’s the File & Registry Shim, which virtualizes file system operations; the CreateProcess Shim, which allows an add-on to launch another process at Medium, with user consent; and the CoCreateInstance Shim, which allows an add-on to launch a COM server at Medium, again only with user consent.
Since a Low process lacks the privilege to write to most locations in the file and registry, the File & Registry Compat Shim virtualizes some common file system folders and registry keys. Those file and registry locations are redirected to per-user Low-integrity virtual locations where they can’t affect the real versions. The virtualized file system is in the Temporary Internet Files (TIF)—the same general place IE caches web files. If an add-in attempts to append to an existing file, the shim applies a “copy-on-write” approach, first copying the file to the corresponding virtual location, with the actual append happening only to the virtualized version. If the add-in attempts a file and a real version of a file and a virtualized version both exist, the shim makes the add-in read the virtualized version. The shim does not otherwise affect reads. Registry virtualization works similarly. Note that Vista's UAC virtualization does not apply to Protected Mode; if an add-in attempts to write to sensitive areas will not be redirected and they will just get an Access Denied error.
For example, the Compat Shim virtualizes the UserProfile folder (real location %userprofile%) to the TIF location %userprofile%\AppData\Local\Microsoft\Windows\Temporary Internet Files\Virtualized\{system drive letter}\Users\{username}.
An example of a file system location to which an add-in is simply denied access is %userprofile%\AppData\Roaming\Microsoft\Windows\Cookies
As an example of the registry virtualization, the Compat Shim virtualizes the real registry key HKCU\Software to HKCU\Software\Microsoft\Internet Explorer\InternetRegistry\REGISTRY\USER\{SID}\Software . (A SID is the user's security identifier.)
An example of a registry location where an add-in is simply denied access is HKCU\Software\Classes.
The CreateProcess Shim intervenes when an add-in attempts to launch a process using CreateProcess() or equivalent API. The shim presents an “elevation dialog” to the user, asking the user whether they want to run the app at a higher privilege level than IE. If the user assents, the app is allowed to launch at Medium level. If the user says no, the app is not launched. The CoCreateInstance Shim works similarly but kicks in when an add-in attempts to launch a COM server.
To optimize user experience, the registry has Elevation Opt-In Lists for CreateProcess and COM (at HKLM\Software\Microsoft\Internet Explorer\Low Rights; there's also a per-user version in HKCU). These allow-lists can enable Protected Mode IE to silently launch specified apps or COM servers at elevated privilege levels, among other options. When it’s necessary to launch a non-IE process with admin privileges, you would include the RequestedExecutionLevel marking in the application manifest.
The compatibility layers should allow most legacy add-ons to just work without requiring any modification. Protected Mode provides a set of APIs that new and existing add-ins can make use of to work natively in Protected Mode. For example, IEIsProtectedMode() lets an add-in find out if IE is running in Protected Mode. The IEGetWriteableFolderPath() and IEGetWriteableHKCU() functions find low-integrity locations to which the add-in can write. To save a file outside the TIF so that users and apps can later find the file, an add-in employs a two-step procedure, first calling the IEShowSaveFileDialog() function to get the user's consent and desired user profile location, and then calling IESaveFile() to write to that location. Add-in writers also can create their own broker processes if needed for custom elevated operations.
For further information:
Introduction to the Protected Mode API
Understanding and Working in Protected Mode Internet Explorer
User Account Control White Paper
- Mike
Update: Updated to fix a minor error.
