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