Skip to content

Skip to breadcrumbs

Skip to header menu

Skip to action menu

Skip to quick search

Linked Applications

Home

Blade®

HstEx®

NetAnalysis®

Support

Knowledge Base

Spaces

Quick Search

Help

Online Help

Keyboard Shortcuts

Feed Builder

What’s new

Available Gadgets

About Confluence

Log in

Browser Forensics

Pages

Space shortcuts

NetAnalysis

HstEx

Blade

Page tree

Apple Safari

Google Chrome

Microsoft Browsers

Internet Explorer

Daily INDEX.DAT Entries

Document Object Model Web Storage

IE Cache Record Visit, Expiry and Modification Timestamps

IETldCache INDEX.DAT Records

INTERNET_CACHE_ENTRY_INFO Structure

Internet Code Download Log

Internet Explorer Cache

Internet Explorer Cache Location

Internet Explorer Compatibility

Internet Explorer LEAK Record Entries

Location of Internet Explorer 10 Data

Location of Internet Explorer 11 Data

Location of Internet Explorer Data

Mm256.dat and Mm2048.dat Files

MMS URL Scheme - Microsoft Media Server

PrivacIE Entries

Random Cookie Names

Redirects

Temporary Internet files Primer

Understanding and Working in Protected Mode Internet Explorer

Userdata Scheme

Weekly INDEX.DAT Entries

Microsoft Edge Legacy

Mozilla Firefox

Opera

Other Web Browsers

Technical Articles

Browse pages

ConfigureSpace tools

Overview

Content Tools

Browse pages

Attachments (2)

Page History

Page Information

Resolved comments (0)

Link to this Page…

View in Hierarchy

View Source

Export to PDF

Export to Word

Pages

…

Browser Forensics and Analysis

Microsoft Browsers

Internet Explorer

Skip to end of banner

JIRA links

Go to start of banner

Understanding and Working in Protected Mode Internet Explorer

Skip to end of metadata

Created by Craig Wilson, last modified on Jun 07, 2013

Go to start of metadata

Summary

In Windows Vista, Internet Explorer 7 runs in Protected Mode, which helps protect users from attack by running the Internet Explorer process with greatly restricted privileges. Protected Mode significantly reduces the ability of an attack to write, alter, or destroy data on the user's machine or to install malicious code.

This topic introduces Protected Mode, describes the Windows Vista features used to implement Protected Mode, shows how to develop extensions that work with Protected Mode, and provides guidelines for developing more secure applications.

Contents

1Summary

2Contents

3Understanding Protected Mode

3.1Introducing Protected Mode

3.2Understanding Windows Vista's Integrity Mechanism

3.3Understanding Protected Mode

3.3.1Configuring Protected Mode

3.4Working with Protected Mode

3.4.1Finding Low Integrity Write Locations

3.4.2Saving Files to the User Profile

3.4.3Starting Processes from Protected Mode

3.4.4Allowing Drag and Drop Operations in your Application

3.4.5Allowing Applications to Receive Window Messages

3.4.6Launching and Navigating a Protected Mode Process

3.4.7Debugging with the Application Compatibility Toolkit

3.5Designing Secure Extensions

3.5.1Installing Software from Extensions

3.5.2Starting Low Integrity Processes

3.5.3Lowering Resource Integrity

3.5.4Determining Process Integrity Levels

3.6Frequently Asked Questions

3.7Acknowledgements

4Reference

Understanding Protected Mode

Protected Mode is an important step forward in security for Internet Explorer (IE); it helps protect users from attack by running an IE process with greatly restricted privileges on Windows Vista. While Protected Mode does not protect against all forms of attack, it significantly reduces the ability of an attack to write, alter, or destroy data on the user's machine or to install malicious code.

Introducing Protected Mode

While most Internet Explorer 7 security features will be available in Internet Explorer 7 for Windows XP Service Pack 2, Protected Mode is available only on Windows Vista because it is based on security features new to Windows Vista:

User Account Control (UAC) makes it easy to run without Administrator privileges. When users run programs with limited user privileges, they are safer from attack than when they run with Administrator privileges because Windows can restrict the malicious code from carrying out damaging actions.

The integrity mechanism restricts write access to securable objects by lower integrity processes, much the same way that user account group membership restricts the rights of users to access sensitive system components.

User Interface Privilege Isolation (UIPI) prevents processes from sending selected window messages and other USER APIs to processes running with higher integrity.

The Windows Vista security infrastructure allows Protected Mode to provide Internet Explorer with the privileges needed to browse the web while withholding privileges needed to silently install programs or modify sensitive system data.

This section helps you understand Protected Mode, describes the Windows Vista integrity access levels, and summarizes the compatibility impact for Internet Explorer extensions.

Understanding Windows Vista's Integrity Mechanism

Windows Vista includes an addition to the access control security mechanism of Windows that labels processes and other securable objects with an integrity level. Internet-facing programs are at higher risk for exploits than other programs because they download untrustworthy content from unknown sources. Running these programs with fewer permissions, or at a lower integrity level, than other programs reduces the ability of an exploit 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. The main features of the integrity level mechanism in Windows Vista are as follows:

Securable objects, such as 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). The new mandatory ACE is 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 run from the Start menu have a medium integrity level. Applications that require administrator permissions run with a high integrity level.

Low integrity processes cannot gain write access to objects at higher integrity levels, even if the user's SID is granted write access in the discretionary access control list (DACL). Integrity level checks are performed before user access permission checks.

All files and registry keys on 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 process, such as Internet Explorer in Protected Mode, 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. The Windows Vista integrity mechanism automatically assigns low integrity mandatory labels to securable objects created by low integrity processes. As a result, all files and other objects created by Internet Explorer in Protected Mode or any other low integrity process are automatically assigned low integrity mandatory labels. By default, child processes started by a low integrity process will also run with a low integrity level.  Protected Mode allows processes to be created with higher integrity.  For details, see Starting Processes from Protected Mode section.

The following table shows supported integrity access levels and the privileges they confer.

Integrity Access Level (IL)

System Privileges

Integrity Access Level (IL)

System Privileges

High

Administrative (Process can install files to the Program Files folder and write to sensitive registry areas like HKEY_LOCAL_MACHINE.)

Medium

User (Process can create and modify files in the user's Documents folder and write to user-specific areas of the registry, such as HKEY_CURRENT_USER.)

Low

Untrusted (Process can write only to low integrity locations, such as the Temporary Internet Files\Low folder or the HKEY_CURRENT_USER\Software\LowRegistry key.)

Understanding Protected Mode

Protected Mode builds on the new integrity mechanism to restrict write access to securable objects like processes, files, and registry keys with higher integrity levels. When run in Protected Mode, Internet Explorer is a low integrity process; it cannot gain write access to files and registry keys in a user's profile or system locations.

Low integrity processes can write only to folders, files, and registry keys that have been assigned a low integrity mandatory label. As a result, Internet Explorer and extensions run in Protected Mode can write only to low integrity locations, such as the new low integrity Temporary Internet Files folder, the History folder, the Cookies folder, the Favorites folder and the Windows temporary file folders.  For a complete list, see the Frequently Asked Questions (FAQ) section.

Furthermore, Protected Mode can send only specific window messages to higher integrity processes. For more information, please see the User Interface Privilege Isolation Overview section of Developer Best Practices and Guidelines for Applications in a Least Privileged Environment.

By preventing unauthorized access to sensitive areas of a user's system, Protected Mode limits the amount of damage that can be caused by a compromised IE process. An attacker cannot, for example, silently install a keystroke logger to the user's Startup folder. Likewise, a compromised process cannot manipulate applications on the desktop through window messages.

Of course, these defenses also limit legitimate changes to higher integrity locations. As a result, Protected Mode provides a compatibility architecture that reduces the impact on existing extensions, as shown in the following figure.

Compatibility Layer handles the needs of many existing extensions. It intercepts attempts to write to medium integrity resources, such as the Documents folder in the user profile and the HKEY_CURRENT_USER registry hive. However it will not intercept writes to system locations like Program Files and HKEY_LOCAL_MACHINE.  The compatibility layer uses a Windows Compatibility Shimto automatically redirect these operations to the following low integrity locations:

Documents and Settings\%userprofile%\LocalSettings\TemporaryInternet Files\Virtualized

HKEY_CURRENT_USER\Software\Microsoft\InternetExplorer\InternetRegistry

Two higher privilege broker processes allow Internet Explorer and extensions to perform elevated operations given user consent. For example, the user privilege broker (IEUser.exe) process provides a set of functions that let the user save files to areas outside of low integrity areas. In addition, an administrator privilege broker (IEInstal.exe) process allows Internet Explorer to install ActiveX controls.

For more information, please see Working with Protected Mode.

Configuring Protected Mode

Protected Mode can be configured in Internet Explorer's Internet Options dialog. To configure Protected Mode, click the Security tab, select a Web content zone, and then change the Enable Protected Mode check box. By default, Protected Mode is enabled for the Internet, Intranet, and Restricted Sites zones.  To verify that Internet Explorer is running in Protected mode, look for the words "Protected Mode: On" next to the Web content zone displayed in Internet Explorer's status bar.

Protected Mode will be configurable through Group Policy when Windows Vista ships, through the URLACTION_LOWRIGHTS (0x00002500)URL Action.  For more information, please see URL Security Zones Overviews.

Working with Protected Mode

This section shows how extensions can perform common tasks while in Protected Mode. It explains how to find low integrity object locations, save files outside low integrity file locations, elevate processes out of Protected Mode, and debug Protected Mode access failures.

Finding Low Integrity Write Locations

In Windows Vista, securable objects automatically inherit the lower integrity level between the process that created them and their container.  As a result, files or registry keys have a low integrity when created in Protected Mode. This means that a low integrity process can obtain write access to the objects it creates. However, a low integrity process cannot gain write access to medium or high integrity folders or files in the user's profile.

Before writing to a low integrity location, extensions can determine whether Internet Explorer is running in Protected Mode by calling the IEIsProtectedModeProcess function. When in Protected Mode, extensions can write files to a folder below the user's UserProfile folder, typically %userprofile%\AppData\LocalLow. Use the SHGetKnownFolderPath function with the FOLDERID_LocalAppDataLow flag to obtain the expanded folder name.

SHGetKnownFolderPath(FOLDERID_LocalAppDataLow, 0,
NULL, szPath, ARRAYSIZE(szPath));

Note  Protected Mode modifies IE's environment variables.  As a result, the GetTempPath() function returns %Temp%\Low when called while Protected Mode is active.

Low integrity processes can create and write to low integrity subkeys of the registry, such as HKEY_CURRENT_USER\Software\AppDataLow. However, extensions running in Protected Mode's low integrity process can write only to specific low integrity locations and should use IEGetWriteableHKCU to obtain a low integrity registry location.

Security Alert  Take care to avoid mixing integrity levels. Low integrity objects should be stored separately from medium or high integrity objects.  In addition, medium and high integrity applications should not open low integrity objects without proper validation.

Saving Files to the User Profile

Some extensions need to save files to a particular location so that users or applications can later find the files. The following steps show how to save a file outside of a low integrity location:

Create a temporary version of the file in %userprofile%\AppData\LocalLow.  Remember to delete the temporary file after the file is sucessfully saved.

Call IEShowSaveFileDialog with the location of the user's profile folder to prompt the user to save the file in a different location. If the user accepts the Save As dialog, IEShowSaveFileDialog returns the chosen destination folder.

Call IESaveFile with the location of the temporary file saved in Step 1.

When you do this, Protected Mode's user broker copies the file from the temporary location to the location selected by the user.

To obtain write access to other medium integrity objects, use a custom broker process and then elevate your broker to a medium level process. When run as medium level processes, broker objects can access medium integrity objects. For more information, see Starting Processes from Protected Mode.

Starting Processes from Protected Mode

In general, extensions should operate as low integrity processes whenever possible. This provides the best protection against malicious attacks. However, there are times when an extension may need to access medium or even high integrity objects.

To do this, create a broker process to access higher integrity objects and then launch the broker process with a higher integrity level. By default, Internet Explorer will prompt the user to confirm the medium integrity elevated process, as shown in the following screen shot.

Set the name of the new key to the GUID created for your policy and then add the following settings to the key:

Policy (DWORD) indicates how Protected Mode should launch the broker. The following table describes the supported values.

Value

Result

Value

Result

3

Protected Mode silently launches the broker as a medium integrity process.

2

Protected Mode prompts the user for permission to launch the process. If permission is granted, the process is launched as a medium integrity process.

1

Protected Mode silently launches the broker as a low integrity process.

0

Protected Mode prevents the process from launching.

If your broker is an executable file, add the following settings to your policy:

AppName (REG_SZ) is the file name of your broker's executable file.

AppPath (REG_SZ) is the user-selected installation location of your broker's executable file.

If your extension launches a COM server through CoCreateInstance,         add a REG_SZ value called CLSID containing the CLSID of the COM server and add the following setting to your policy.

CLSID (REG_SZ) contains the CLSID of your extension.

To illustrate, the following policy would silently elevate a fictional broker called contoso.exe to medium integrity level.

Note  For security reasons, Internet Explorer in Protected Mode ignores parameters that change the working directory of createProcess, createProcessAsUser, and related functions. If your process must accept working directory parameters, use a logical XOR operation to add
0x80000
to the value of the Policy setting of the elevation policy for your application. Be aware that this can create a security risk; as a result, it is strongly discouraged.

If Microsoft determines that an application has a vulnerability and presents a danger to end users, Microsoft reserves the right to remove that application at any time from the elevation policy.

You can also create broker processes to access high integrity objects.  For information describing how to launch broker processes with a high integrity level, please see the Guidelines for Administrative User Applications section of Developer Best Practices and Guidelines for Applications in a Least Privileged Environment.  Note that you do not need to create an elevation policy because UAC will handle the elevation.

If your existing extension uses rundll32.exe to host a DLL library, you can silently launch a rundll32.exe process with low integrity by adding the library's file name to the following key.

The following example shows the setting that would silently load the fictional contoso.dll library with low integrity using rundll32.exe.

Note  The best practice is to create a custom .exe file to host DLLs and not use rundll32.exe.

Allowing Drag and Drop Operations in your Application

By default, Protected Mode prompts the user before allowing web content to be copied to a higher integrity process.

You can register your application to avoid this prompt and silently accept web content from a drag-and-drop operation by creating a DragDrop policy. DragDrop policies must have a globally unique identifier (GUID) associated with them.  Use CreateGuid to create a new GUID for your policy.  Next, add a key to the following location.

Set the name of the new key to the GUID created for your policy and then add the following settings to the key:

Policy (DWORD) should be set to 3, which tells Protected mode to allow web content to be silently copied to your application process.

If your application is an executable file, add the following settings to your policy:

AppName (REG_SZ) is the file name of your application executable file.

AppPath (REG_SZ) is the user-selected installation location of your application's executable file.

If your extension launches a COM server that is not registered in HKEY_CLASSES_ROOT, or gets dynamically registered through COM and launched via CoCreateInstance, add a REG_SZ value called CLSID containing the CLSID of the COM server, add the following setting to your policy.

CLSID (REG_SZ) contains the CLSID of your extension.

The following example shows the setting that would allow web content to be silently copied to fictional contoso.exe application.

Allowing Applications to Receive Window Messages

As mentioned above, UIPI blocks window messages from low to higher integrity processes. If your extension running in Protected mode needs to communicate with an evelated application using window messages, you can call ChangeWindowMessageFilter() from the elevated application to allow specific messages though.

Note  The best practice is to run your application with low integrity if you are communicating with Protected Mode. Otherwise use only secure forms of interprocess communication (IPC), such as remote procedure calls (RPC), to communicate between Protected Mode and a higher integrity process.

Launching and Navigating a Protected Mode Process

If your application uses CreateProcess to launch IE, it should call IELaunchURL on Windows Vista. This will ensure that your application gets the right return values and that IE launches in Protected mode for URLs whose zone has Protected Mode on. If you need to determine whether a specific URL will open in a low (Protected Mode) or a medium integrity IE process before launching IE, call IEIsProtectedModeURL. Note that a high integrity process with administrator privileges will launch a high integrity IE process with Protected Mode off. If you want to launch Protected Mode from your high integrity process, then first create a medium integrity process, which will launch your high integrity process and IE.

If your application launches Internet Explorer using CoCreateInstance and you need to continue controlling navigations after IE is launched, you can use IWebBrowser2 to navigate Internet Explorer programmatically. You can continue controlling navigations after IE is launched only if your application has the same integrity level as the IE process launched. After your application navigates to URL in a different integrity IE process, you can not perform additional navigations. You should make the IE frame visible after navigation.

The following example shows how you would do this in C++.

hr = CoCreateInstance(CLSID_InternetExplorer, NULL, CLSCTX_LOCAL_SERVER,
IID_IWebBrowser2,(LPVOID*)&pIWebBrowser2);
hr = pIWebBrowser2->Navigate(bstrUrl, &vEmpty, &vEmpty, &vEmpty, &vEmpty);
hr = pIWebBrowser2->put_Visible(VARIANT_TRUE);

The following example shows the JScript version.

var ie = new ActiveXObject("InternetExplorer.Application");
ie.Navigate("http://www.msn.com");
ie.visible = true;

Debugging with the Application Compatibility Toolkit

Protected Mode works with the Microsoft Application Compatibility Toolkit introduced with Windows XP Service Pack 2.

When Internet Explorer or its extensions attempt to write to securable objects in Protected Mode, the application compatibility logs contain entries that describe the operation and its results. The following list explains the values in the log entries:

ModuleName is the file name that launched the process accessing securable objects.

VirtualizationAction indicates the result of the write operation and is one of the following values:

InterceptedWrite indicates that the operation was intercepted by the Compatibility Layer.

WriteIgnored indicates that the operation was ignored by Protected Mode because the attempting process is an elevated broker.

CreateVirtualCopy indicates that the Compatibility Layer made a copy of the object in the virtual location.

CreateNew indicates that the Compatibility Layer created a new object in the virtual location.

ObjectType is either File or Registry.

APIName specifies the function attempting the operation, for example CreateFile or RegOpenKey.

ReqObjectPath is the location of the object the operation object attempted to modify. This is blank for objects that do not have paths.

When write operations succeed, NewObjectPath specifies the object that was modified by the operation.

APIResult indicates the result returned by the API function attempting the write operation.

LastError is the last error received by an API function.

This information can be invaluable when trying to determine why operations do not behave as expected.

Designing Secure Extensions

Developing secure Internet Explorer extensions for Protected Mode is not that different from developing secure applications for Windows Vista. In addition to understanding the guidelines offered in Developer Best Practices and Guidelines for Applications in a Least Privileged Environment and ActiveX Security: Improvements and Best Practices, extension developers should understand how to install software from extensions, start low integrity processes, lower resource integrity levels, and determine process integrity levels. This section shows how to perform these tasks.

Installing Software from Extensions

When running in Protected Mode, ActiveX controls and other extensions cannot install software. If your extension needs to modify high integrity objects, such as the Program files or registry keys under HKEY_LOCAL_MACHINE, you should create a standalone installation application that can be run with administrator privileges.

To launch your application with administrator privileges, you can include an application manifest as detailed in the Developer Best Practices and Guidelines for Applications in a Least Privileged Environment.  After installation, your extension running in Protected Mode can launch your application with medium integrity instead of launching it from the installation application with high integrity. This helps protect the user because the application is running with user privileges instead of administrator privileges.

If you add to the elevation policy, you need to close and restart any open Internet Explorer processes.  IEUser.exe does not automatically detect and respond to elevation policy changes.

Starting Low Integrity Processes

By default, child processes inherit the integrity level of the parent process. To start a low integrity process from Protected Mode, call CreateProcessAsUser.  To start a low integrity process from a medium integrity process, you have to explicitly start the new process as low integrity. This is a three step process:

Duplicate the handle of the medium integrity process.

Use SetTokenInformation to lower the process handle to low integrity.

Use CreateProcessAsUser to create a new process using the low integrity handle.

The following code sample demonstrates this process.

#include <sddl.h>

void CreateLowProcess()
{
BOOL bRet;
HANDLE hToken;
HANDLE hNewToken;

// Notepad is used as an example
WCHAR wszProcessName[MAX_PATH] =
L"C:\\Windows\\System32\\Notepad.exe";

// Low integrity SID
WCHAR wszIntegritySid[20] = L"S-1-16-4096";
PSID pIntegritySid = NULL;

TOKEN_MANDATORY_LABEL TIL = {0};
PROCESS_INFORMATION ProcInfo = {0};
STARTUPINFO StartupInfo = {0};
ULONG ExitCode = 0;

if (OpenProcessToken(GetCurrentProcess(),MAXIMUM_ALLOWED, &hToken))
{
if (DuplicateTokenEx(hToken, MAXIMUM_ALLOWED, NULL,
SecurityImpersonation, TokenPrimary, &hNewToken))
{
if (ConvertStringSidToSid(wszIntegritySid, &pIntegritySid))
{
TIL.Label.Attributes = SE_GROUP_INTEGRITY;
TIL.Label.Sid = pIntegritySid;

// Set the process integrity level
if (SetTokenInformation(hNewToken, TokenIntegrityLevel, &TIL,
sizeof(TOKEN_MANDATORY_LABEL) + GetLengthSid(pIntegritySid)))
{
// Create the new process at Low integrity
bRet = CreateProcessAsUser(hNewToken, NULL,
wszProcessName, NULL, NULL, FALSE,
0, NULL, NULL, &StartupInfo, &ProcInfo);
}

LocalFree(pIntegritySid);
}
CloseHandle(hNewToken);
}
CloseHandle(hToken);
}
}

Note  You can also launch low integrity processes from Protected Mode by setting a registry key.  For more information, please see Launching Processes.

Lowering Resource Integrity

Generally, it is not a good security practice for higher level processes to accept input or share resources with low integrity processes. There is a risk that the low integrity process may attempt malicious behavior. However, there are times when this is required by design.

Note  Applications that accept input or share resources from lower integrity processes should assume that data provided by lower integrity processes cannot be trusted and then perform appropriate validation. For example, Protected Mode displays the Save As dialog box from the Internet Explorer User Broker process; this allows the user to confirm that they want to save a file using a process that runs with higher privileges than Protected Mode.

Because low integrity applications can write only to low integrity resources, you need to lower the integrity level of the shared resources:

Create an SDDL security descriptor that defines a Low mandatory label.

Convert the SDDL string to a security descriptor.

Assign the low integrity attribute to the security descriptor.

Assign the security descriptor to the shared resource.

The following code sample shows this process.

#include <sddl.h>
#include <AccCtrl.h>
#include <Aclapi.h>

void SetLowLabelToFile()
{
// The LABEL_SECURITY_INFORMATION SDDL SACL to be set for low integrity
#define LOW_INTEGRITY_SDDL_SACL_W L"S:(ML;;NW;;;LW)"
DWORD dwErr = ERROR_SUCCESS;
PSECURITY_DESCRIPTOR pSD = NULL;

PACL pSacl = NULL; // not allocated
BOOL fSaclPresent = FALSE;
BOOL fSaclDefaulted = FALSE;
LPCWSTR pwszFileName = L"Sample.txt";

if (ConvertStringSecurityDescriptorToSecurityDescriptorW(
LOW_INTEGRITY_SDDL_SACL_W, SDDL_REVISION_1, &pSD, NULL))
{
if (GetSecurityDescriptorSacl(pSD, &fSaclPresent, &pSacl,
&fSaclDefaulted))
{
// Note that psidOwner, psidGroup, and pDacl are
// all NULL and set the new LABEL_SECURITY_INFORMATION
dwErr = SetNamedSecurityInfoW((LPWSTR) pwszFileName,
SE_FILE_OBJECT, LABEL_SECURITY_INFORMATION,
NULL, NULL, NULL, pSacl);
}
LocalFree(pSD);
}
}

Application processes can set the integrity levels of securable objects only to those at or below the application process.

Windows Vista allows object owners to change the integrity access level of a securable object. Such changes will not update audit logs.

Processes with READ_CONTROL privileges for a securable object can use GetNamedSecurityInfo to determine the object's integrity level.

Note  Even low integrity files will get redirected by Protected Mode's compatibility shim except for known locations mentioned in the frequently asked questions.

Determining Process Integrity Levels

Extensions that can run in different processes might want to check if the code is running in a process at Low or Medium integrity level and modify behavior accordingly. The following steps show how to determine the integrity level of a process:

Open a handle to the current process's token.

Get the integrity level of the token.

Compare the integrity level SID to the system defined integrity level RIDs.

The following code sample shows how to do this.

void ShowProcessIntegrityLevel()
{
HANDLE hToken;
HANDLE hProcess;

DWORD dwLengthNeeded;
DWORD dwError = ERROR_SUCCESS;

PTOKEN_MANDATORY_LABEL pTIL = NULL;
LPWSTR pStringSid;
DWORD dwIntegrityLevel;

hProcess = GetCurrentProcess();
if (OpenProcessToken(hProcess, TOKEN_QUERY |
TOKEN_QUERY_SOURCE, &hToken))
{
// Get the Integrity level.
if (!GetTokenInformation(hToken, TokenIntegrityLevel,
NULL, 0, &dwLengthNeeded))
{
dwError = GetLastError();
if (dwError == ERROR_INSUFFICIENT_BUFFER)
{
pTIL = (PTOKEN_MANDATORY_LABEL)LocalAlloc(0,
dwLengthNeeded);
if (pTIL != NULL)
{
if (GetTokenInformation(hToken, TokenIntegrityLevel,
pTIL, dwLengthNeeded, &dwLengthNeeded))
{
dwIntegrityLevel = *GetSidSubAuthority(pTIL->Label.Sid,
(DWORD)(UCHAR)(*GetSidSubAuthorityCount(pTIL->Label.Sid)-1));

if (dwIntegrityLevel < SECURITY_MANDATORY_MEDIUM_RID)
{
// Low Integrity
wprintf(L"Low Process");
}
else if (dwIntegrityLevel >= SECURITY_MANDATORY_MEDIUM_RID &&
dwIntegrityLevel < SECURITY_MANDATORY_HIGH_RID)
{
// Medium Integrity
wprintf(L"Medium Process");
}
else if (dwIntegrityLevel >= SECURITY_MANDATORY_HIGH_RID)
{
// High Integrity
wprintf(L"High Integrity Process");
}
}
LocalFree(pTIL);
}
}
}
CloseHandle(hToken);
}
}

Frequently Asked Questions

Q: Does UAC file and registry virtualization apply to Protected Mode?

A: No, UAC virtualization does not apply to Protected Mode and, therefore, write access to Protected Mode extensions that write to sensitive areas will not be redirected.

Protected Mode also does not have write access to the redirected or virtual store for system areas. Extensions running in Protected Mode get an Access Denied error when they attempt to write to sensitive system areas.

Q: Are there specific locations in the USER PROFILE or HKEY_CURRENT_USER registry location that an extension in Protected Mode Internet Explorer can not write to?

A: Yes, Internet Explorer-specific locations in the following USER PROFILE folders:

Documents and Settings\%USER PROFILE%...   ...\Local Settings\Temporary Internet Files ...\Local Settings\Temp ...\Local Settings\History  ...\%USER PROFILE%\Favorites  ...\%USER PROFILE%\Cookies

Extensions can write to the following locations:

Documents and Settings\%USER PROFILE%...   ...\Local Settings\Temporary Internet Files\Low ...\Local Settings\Temp\Low ...\Local Settings\History\Low  ...\%USER PROFILE%\Favorites\Low  ...\%USER PROFILE%\Cookies\Low  %USER PROFILE%\AppData\LocalLow

Note that extensions cannot write to system locations such as the Program Files folder or the HKEY_CLASSES_ROOT or HKEY_LOCAL_MACHINE subtrees.

Furthermore, extensions that attempt to gain write access to securable objects by using an API function in one of the following binary files will receive Access Denied errors.

actxprxy.dll

ieui.dll

mswsock.dll

sensapi.dll

Advapi32.dll

iexplore.exe

NAPINSP.dll

Shdocvw.dll

bcrypt.dll

IMM32.dll

ncrypt.dll

SHLWAPI.dll

BrowseUI.dll

Inetcpl.cpl

NETAPI32.dll

SWEEPRX.dll

clbcatq.dll

IPHLPAPI.dll

NLAapi.dll

TAPI32.dll

Comctl32.dll

jscript.dll

NSI.dll

URLMon.dll

Corpol.dll

jsproxy.dll

Ntdll.dll

USERENV.dll

CREDSSP.dll

Kernel32.dll

ntmarta.dll

USP10.dll

Crypt32.dll

LPK.dll

offprof.dll

uxtheme.dll

Cryptnet.dll

mf.dll

OLEACC.dll

vbscript.dll

dciman32.dll

mlang.dll

pnrpnsp.dll

Wininet.dll

ddraw.dll

MPR.dll

PSAPI.dll

WINNSI.dll

dhcpcsvc.dll

MSASN1.dll

rasadhlp.dll

winrnr.dll

dhcpcsvc6.dll

mscms.dll

rasapi32.dll

WINSPOOL.DRV

DNSAPI.dll

MSCTF.dll

rasdlg.dll

winsta.dll

dssenh.dll

msfeeds.dll

rasman.dll

Wintrust.dll

dwmapi.dll

msfeedsbs.dll

rpcrt4.dll

ws2_32.dll

Dxtmsft.dll

Mshtml.dll

rsaenh.dll

wship6.dll

Dxtrans.dll

MSHTMLED.dll

rtutils.dll

wshtcpip.dll

gpapi.dll

msimg32.dll

samlib.dll

wsock32.dll

Ieframe.dll

msimtf.dll

Schannel.dll

wtsapi32.dll

IEPeers.dll

msls31.dll

secur32.dll

iertutil.dll

Mstime.dll

Secure32.dll

Q: How do I stop my toolbar from launching an elevated Internet Explorer process?

A: Many toolbar installations close all running instances of Internet Explorer and launch a new one when their setup is finished, so that the new toolbar is visible. The problem is that the new Internet Explorer is launched from an elevated process and, therefore, is also elevated. Toolbars can avoid this problem by closing down Internet Explorer and re-launching it with a lower integrity level.  For more information, please see Starting Low Integrity Processes.

Acknowledgements

We would like to thank the following for their help in preparing and reviewing this article: Robert Gu, Vidya Nallathimmayyagari, Jeremy Epling, Sharath Udupa, Hao-Wei Liu, Bogdan Tepordei, Lance Leonard, and Will Mason.

Marc Silbey and Peter Brundrett are program managers on the Internet Explorer and Windows Security teams.

Reference

http://msdn.microsoft.com/en-us/library/bb250462(v=vs.85).aspx

msie

low

protected

integrity

Overview

Content Tools

Powered by Atlassian Confluence 5.10.9

Printed by Atlassian Confluence 5.10.9

Report a bug

Atlassian News

Atlassian

{"serverDuration": 47, "requestCorrelationId": "94440d78b565afb6"}

Browser Forensics

Pages

…

Browser Forensics and Analysis

Microsoft Browsers

Internet Explorer

Understanding and Working in Protected Mode Internet Explorer

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.

search

attachments

weblink

advanced

image-effects

image-attributes

Paragraph

Paragraph

Heading 1

Heading 2

Heading 3

Heading 4

Heading 5

Heading 6

Preformatted

Quote

Bold

Italic

Underline

Colour picker
More colours

Formatting

Strikethrough

Subscript

Superscript

Monospace

Clear formatting

Bullet list

Numbered list

Task list

Outdent

Indent

Align left

Align center

Align right

Page layout

Link

Table

Insert

Insert content

Files and images

Link

Symbol

Emoticon

Markup

Horizontal rule

Task list

Insert macro

User mention

JIRA Issue/Filter

Info

Status

Gallery

Table of Contents

Other macros

Page layout

No layout

Two column (simple)

Two column (simple, left sidebar)

Two column (simple, right sidebar)

Three column (simple)

Two column

Two column (left sidebar)

Two column (right sidebar)

Three column

Three column (left and right sidebars)

Undo

Redo

Find/Replace

Keyboard shortcuts help

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account.

This page is also being edited by . Your changes will be merged with theirs when you save.

Edit

Preview

Save
Cancel

Discard unpublished changes

This will restore the editor to the last published version of this page. If anyone else has unpublished changes on the page, you'll be discarding those changes too.

Key:
This line was added.
This line was removed.
Formatting was changed.

Discard
See changes
Close

Discard
Close