document.implementation & redirect exploit

VERIFIED FIXED

Status

()

Core
Security
P3
normal
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: Mitchell Stoltz (not reading bugmail), Assigned: Mitchell Stoltz (not reading bugmail))

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: need engineer feedback, URL)

Attachments

(1 attachment)

document.implementation.createDocument vulnerability - reading arbitrary
XML files using HTTP redirects
This page reads xml2.xml and shows the first tag name but easily may be
modified to enumarate the whole DOM.
The code is:
---------------------------------
<SCRIPT> d=document.implementation.createDocument("","",null);
d.load("http://ORIGINATINGHOST/SOMETHINGTTHATREDIRECTSTO_XML2.XML","text/xml");
setTimeout("alert('tagname='+d.documentElement.tagName);",2000);
//setTimeout("alert(d.firstChild);",2000);
</SCRIPT> ---------------------------------


document.implementation.createDocument vulnerability - reading arbitrary XML
files using HTTP redirects
This page reads xml2.xml and shows the first tag name but easily may be modified
to enumarate the whole DOM.
Written by Georgi Guninski



<test> xml
</test>

Updated

18 years ago
QA Contact: czhang → junruh
(Assignee)

Comment 1

18 years ago
document.implementation needs a thorough security review.
Status: NEW → ASSIGNED

Comment 2

18 years ago
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
(Assignee)

Comment 3

18 years ago
All right, finally able to reproduce this. Adding URL for testcase above. Sorry
it's NS-internal, I needed a server that could be reconfigured for a redirect.
Basically, this does
document.load("http://grey/u/mstoltz/bugs/redirect_to_xmlbase.xml");
and the URL in the above call is redirected to
"http://grey.mcom.com/u/mstoltz/bugs/xmlbase.xml". Note that the redirected URL
is grey.mcom.com, so Mozilla should treat this as a different host than "grey."
If we loaded an xml document directly from grey.mcom.com, we would not be able
to read its DOM, since it's coming from a different hostname. However, when we
redirect from grey to grey.mcom.com, the principal remains "grey" when it should
be changed to "grey.mcom.com." Obviously, the principal needs to be updated when
the redirect occurs, this happens during a normal document load but not in this
case for some reason.
The reason we don't see the redirect in this case is that we're at a lower level
when we do a document.load() so the code that normally deals with the redir
stuff is not used. I poked around a bit and I came up with a fix for this, the
fix makes the nsXMLDocument an nsIHTTPEventSink and the document is set to get
the callback notifications from necko and once OnRedirect is called I modify the
principal and the testcase fails to access the DOM of the XML document.

I'll attach the patch, pelase have a look and let me know what you think about
the general idea.
Created attachment 19921 [details] [diff] [review]
First stab at a proposed fix
(Assignee)

Comment 6

18 years ago
This patch seems to work fine. The script is no longer able to read the
redirected page, unless the script is run from the same host as the redirected
page. I tried the same testcase without the redirect, and it still enforces
same-origin correctly. r=mstoltz

Comment 7

18 years ago
sr=vidur. The GetInterface() could just unconditionally call QueryInterface()
since the class implements nsIHTTPEventSink. Not a big deal, though.
Fix (including the GetInterface() optimization) checked in. Marking FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED

Comment 9

17 years ago
Sooo...based on mstolz's comments (and my understanding of same origin) because
I get dumped to
http://search.netscape.com/cgi-bin/search?charset=UTF-8&search=grey , this is a
good thing because it didn't load the redirect.

Am I correct in my thinking or am I suffering from UserHeadGap?
Whiteboard: need engineer feedback
(Assignee)

Comment 10

17 years ago
whoops, sorry. No, you got bumped into Netcenter Search because grey is
temporarily offline. It'll be back up sometime this afternoon. The exploit reads
from an XML file that it shouldn't be able to read from and displays some stolen
info in an alert. With the fix, the alert should not show up, and you should (I
think) see a security excption thrown to the JS console. The redirect and the
'stolen' document never actually appear on the screen.

Comment 11

17 years ago
Okay, when I load http://grey/u/mstoltz/bugs/57466.html, I get a page which
looks like this:

<h1>57466</h1>

...
<hr>
<a href="mailto:mstoltz@localhost.localdomain">Mitchell Stoltz</a>
Last modified: Wed Nov 29 15:40:55 PST 2000


And nothing else happens.  After looking over the source, and carefully
re-reading the bug, it appears that there may be another bug blocking this one.

It seems that the 57466.html file should be creating a new document and then
loading an existing xml webpage, but is throwing an
NS_ERROR_DOM_PROP_ACCES_DENIED exception.

Mitch, is this the current expected behaviour?
(Assignee)

Comment 12

17 years ago
You got it, Chris. If you get the access denied error and you don't see an alert
which gives you some of the contents of the XML file, then we're golden.

Comment 13

17 years ago
Beauty.  I guess we're golden then <grin>
Marking Verified FIXED on:
MacOS90 2001-02-13-04-Mtrunk
LinRH62 2001-02-13-06-Mtrunk MOZILLA
Win98SE 2001-02-13-06-Mtrunk
Status: RESOLVED → VERIFIED
(Assignee)

Comment 14

17 years ago
Removing NS_Confidential flag.
Group: netscapeconfidential?
You need to log in before you can comment on or make changes to this bug.