Internet Explorer 9.0.2 Update
Tuesday’s Update for Internet Explorer updates the IE9 Help > About dialog’s version number to v9.0.2. The update includes a number of security and functionality fixes; many of these fixes are described in the More Information section of KB2559049. One fix enables the IE9 Download Manager to properly save files on network drives where the user has limited permissions. Another fix helps ensure that IE8 can properly access sites that advertise IPv6 addresses when those sites are not reachable over IPv6 due to configuration errors on the site or the user’s network.
Two of the security-related changes impact obscure Internet Explorer behaviors in all supported browser versions (IE6 to IE10) -- I’ll discuss both of these changes in this post.
New restrictions on use of the file:// Protocol
Prior to this update, Internet Explorer would allow non-file-protocol (e.g. HTTP and HTTPS)-delivered pages to frame (e.g. using an IFRAME) or navigate to pages that were delivered using the file:// protocol scheme. IE would only block loading of resources from the local computer (e.g. file:///C:/temp/test.gif), but resources from non-local paths would be allowed. Here’s an example page displayed in IE 9.0.1:
And here’s the same page loaded into IE 9.0.2:
Other browsers have blocked cross-protocol interactions for quite some time. Here are screenshots of the Firefox 5, Chrome 14, and Opera 11.5 developer consoles in this scenario:
By default, this new restriction only applies to iexplore.exe and explorer.exe (to support Windows XP). This restriction applies only to pages running in the Internet and Restricted Sites Zones.
We do not expect significant compatibility impact from this change, as no popular sites in the affected Zones rely upon the ability to pull in file://-sourced content. In the event of an problem, the user may add the HTTP/HTTPS site to the Trusted Sites zone and the file-protocol-sourced content will load as it did prior to this update.
Cookie Filenames are Randomized
As a rule, Internet Explorer attempts to prevent Internet sites from storing content in predictable locations on the local computer, in order to foil a number of attack types. That rule is why, for instance, the Internet-cache stores content in randomly-named subfolders.
Prior to this update, Cookies were an exception to this behavior—their location was insufficiently random in many cases. Generally, cookie files were stored under the \AppData\Roaming\Microsoft\Windows\Cookies folder, in files named using the user’s login name, an@ symbol, and a partial hostname for the cookie’s domain:
Given sufficient information about the user’s environment, an attacker might have been able to guess the location of a given cookie and use this information in a multi-stage attack.
To mitigate this threat, Internet Explorer 9.0.2 now names the cookie files using a randomly-generated alphanumeric string. Cookies are not instantly renamed on upgrade, but are instead renamed as soon as any update to the cookie’s data occurs. You can see the impact thusly:
We do not expect significant compatibility fallout from this change either, as the names of these files have always been somewhat dynamic. Directly enumerating or reading the Cookie files has never been supported. Instead, local applications that wish to interact with cookies can use the InternetGetCookieEx and IEGetProtectedModeCookie APIs, or they can use the WinINET cache-enumeration functions.
-Eric
Comments
Anonymous
August 13, 2011
Hmm... I did find it an occasionally useful feature to browse the cookies I have and delete selected ones (or notice interesting cookie sources that I might want to block in future). Will there be an adjustment to Explorer to display the cookies' names, so I can continue with this behaviour? If not, I guess I can live with it, for the security improvement. I love the idea that HTTP / HTTPS can't redirect to FILE - what other protocol interactions are forbidden?Anonymous
August 13, 2011
Change to naming of cookies is somewhat annoyance - I might want to keep majority of them (no need to log again) while clearing broken or unwanted. Maybe beside supporting full clear IE might offer only partiall where user can select which cookies he wants deleted.Anonymous
August 15, 2011
Geez guys, I'll take the security over picking through my cookies anyday. As far as the local file:// handler that is an issue for me when I want to look at XML files and create my own webpages by hand. But I'll bypass the file:// handler in a script when I need to work local, and script back secure when I don't.Anonymous
August 17, 2011
So what is the fix action when the obscure features that is breaks just happen to be a major part of our intranet page?Anonymous
August 17, 2011
@Bill: You should send me email directly to discuss. As noted, this change only applies to the Internet, not the Intranet. If your zone settings are misconfigured such that your Intranet is treated as the Internet, I can help you fix those up.Anonymous
August 23, 2011
user may add the HTTP/HTTPS site to the Trusted Sites zone and the file-protocol-sourced content will load as it did prior to this update. We use Salesforce and it has links to internal documents on our local shares. Adding the sites to the trusted zone has no effect still broken.Anonymous
August 23, 2011
@Jim, you should contact Microsoft Product Support to learn how to properly apply the mitigation for this issue. My guess is that you've added the wrong site to the Trusted Zone.Anonymous
August 23, 2011
We have started getting trouble with one of our sites, which may be related to this update. We set a cookie to a new value, and afterwards, IE sends the cookie twice, with both the old and the new value.Anonymous
August 23, 2011
@Rune: Nope, that's not possibly related to this update. Do you have a URL I could look at? The typical explanation here is that the user visits your site at example.com which sets the cookie and redirects to www.example.com which also sets the cookie without setting a domain attribute which would overwrite the first cookie. IE will subsequently send both cookies, as designed.Anonymous
August 28, 2011
Revisited our Trusted Sites in our GPO and added the address to the server that hosts our intranet homepage and that appears to have fixed the problem.Anonymous
September 09, 2011
Until recently, I could drag an .eml file (a Windows Live Mail message) into a blank IE9 window and it would display. Now I always get an 'Address not valid' error page with something like mhtml:file://C:UsersNBDesktopTest.eml in the address bar. Is this also a consequence of KB2559049 or have I changed something else that would cause this altered behaviour?Anonymous
September 25, 2012
I have accumulated a huge list of blocked tracking/adware/spyware cookies in IE>Tools>Internet options>Privacy>Sites. With the random cookie naming update, will these cookies still be blocked or will I now be flooded with these pernicious nuisances? Obviously I can no longer recognize or Google cookie domains to see if they pose a threat and that alone is annoying enough.Anonymous
September 25, 2012
@Gord: Your existing cookie filters continue to apply. The cookie filenames on disk have no impact on the Cookie Controls. blogs.msdn.com/.../understanding-internet-explorer-cookie-controls.aspxAnonymous
December 05, 2012
In IE9, I have a link displayed by an external server pointing to a local "file:///C:/file.txt" -- an address which works fine when typed into the address bar, but not when the link is clicked. I have added the external server to the trusted sites (when I right click on the page and go to properties, it says "Zone: Trusted sites | Protected Mode: Off") and lowered the trusted sites' security to low. What am I missing?Anonymous
March 19, 2014
I block cookies from all sites by default, and only allow cookies from sites where I need to save my personal settings. Sometimes I have to allow unwanted cookies from other sites. Afterwards, I go to my cookie folder and delete them. It's going to make it harder to find them now. I guess I'll have sort by created date and delete them immediately.