Let’s start off by providing a little history around the challenges seen with Protected Mode and Internet Explorer (first introduced with Internet Explorer 7). In Microsoft Windows Vista, Windows Internet Explorer 7 runs, by default, in Protected Mode. This 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.
Protected Mode IE separates the temporary/persistent data that IE saves from regular LUA (Limited User Account) IE and elevated IE. This is to prevent cross IE injection paths, keeping users secure. However, one of the most significant application compatibility issues remaining with Internet Explorer’s Protected Mode and the low integrity architecture is sharing of cookie data between low and higher integrity processes.
When using winINET APIS, a low process like IE’s Protected Mode can only create and manipulate cookies in the low integrity cookie store: \%USER PROFILE%\Cookies\Low. Similarly, medium integrity (or higher)processes like most applications running on Vista can only create and manipulate cookies in the medium integrity cookie store \%USER PROFILE%\Cookies. As a result, applications that rely on IE to download and share cookies are broken because they do not automatically have access to IE’s cookies.
Here’s an example compatibility issue:
Contoso Networks ships a VPN appliance that connects clients to a server through an SSL connection. Users browse to their company’s SharePoint server through Contoso’s SSL VPN.
When the user logs-in, the server sends back a cookie, which gets stored in Protected Mode’s low integrity cookie folder. Office apps like Word can’t find the cookie since they’re running with medium integrity and can only see the medium integrity cookie folder. As a result Contoso adds their servers to IE’s Trusted Sites list so that they won’t run in Protected Mode and cookies will be downloaded to the medium integrity cookie folder. They’d prefer not to add their sites to the Trusted Sites list.
To work around this issue some vendors ship Browser Helper Objects (BHOs), which run in IE, get a downloaded cookie, and share it with their higher integrity application. This approach is not optimal for two main reasons:
- BHO’s have a negative performance impact to the browser and
- Based on historical data, 3rd party binary code running in the browser is the top cause for reliability and security problems.
Another workaround is to add the websites that write cookies into IE’s Trusted Sites list so that they run out of Protected Mode and write to the medium integrity cookie store. This is not a viable option in many cases, in live messenger for example, the URL is a link that users send to their buddies, adding this to trusted sites to the buddy is not an expected or desirable outcome.
Fortunately, the behavior changes available with installation of Internet Explorer 8.0 provides a much better solution for sharing cookies across integrity level using the IELowUtil.exe process. IE 8 takes advantages of two new APIs for getting and settings cookies that can be shared across integrity levels:
The the above functions call the standard InternetGetCookie() and ExInternetSetCookieEx() functions from a higher-integrity user context to retrieve or create a cookie with a specified name that is associated with a specified URL. The signature and behavior of these two APIs will match the winINET APIs:
So the short answer is that IELowUtil.exe is the broker process that handles operations which require processing at a Low Integrity level. Hopefully this was informative and provides a historical reference regarding this behavior change.
The IE Team