Closed
Bug 403167
Opened 16 years ago
Closed 16 years ago
XSS by using XMLDocument.load() and event handler
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
RESOLVED
FIXED
People
(Reporter: moz_bug_r_a4, Assigned: smaug)
References
Details
(Keywords: verified1.8.1.13, Whiteboard: [sg:high][fixed by 403168])
Attachments
(2 files)
1.18 KB,
patch
|
jst
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
1.74 KB,
patch
|
Details | Diff | Splinter Review |
The fix in bug 393762 stops the testcases in bug 393761 (both XSS and privilege escalation). But, with that fix, it's still possible to perform XSS attacks. 1. Create an XML document (D) whose script handling object is a subframe's global object, and attach an onload event handler to D. 2. Load a target site in the subframe. 3. Call D.load(). The onload event handler is called with the target site's principal.
Reporter | ||
Comment 1•16 years ago
|
||
This tries to get cookies for www.mozilla.com. This works on trunk.
Reporter | ||
Comment 2•16 years ago
|
||
This tries to get cookies for www.mozilla.com. This works on trunk (and fx2.0.0.x and fx1.5.0.x).
Reporter | ||
Comment 3•16 years ago
|
||
This tries to get cookies for www.mozilla.com. This works on trunk.
Updated•16 years ago
|
Flags: blocking1.8.1.10?
Whiteboard: [sg:critical]
Updated•16 years ago
|
Assignee: dveditz → nobody
Component: Security → DOM
QA Contact: toolkit → general
Updated•16 years ago
|
Flags: blocking1.9?
Assignee | ||
Updated•16 years ago
|
Assignee: nobody → Olli.Pettay
Assignee | ||
Comment 4•16 years ago
|
||
Hmm, are there any testcases where information leaks from iframe to main page? I mean something where the data from iframe is really set to some variables in the main page, not just alerts using data from iframe.
Updated•16 years ago
|
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
Assignee | ||
Comment 5•16 years ago
|
||
(In reply to comment #4) > not just alerts using data from iframe. nevermind, idiot me. Jst clarified this in Bug 403168
Assignee | ||
Comment 6•16 years ago
|
||
Fixes testcases. I'm not fully happy with the patch, but I think we have similar problems anyway: if the scriptglobal, to which the document was connected, goes away, javascript handlers in data documents can't be executed. The scriptglobal could be originally got from stack, not from the document which creates the document, but that would just move the problem to different kind of testcases, not remove it. But I need to make a testcase still, to ensure that this XSS is not possible with normal documents.
Assignee | ||
Comment 7•16 years ago
|
||
Comment on attachment 288217 [details] [diff] [review] WIP Jst, can you think of anything better? We don't have similar problem with normal documents, only with data documents. (At least couldn't write testcase to show that kind of bug.)
Attachment #288217 -
Flags: superreview?(jst)
Attachment #288217 -
Flags: review?(jst)
Assignee | ||
Comment 8•16 years ago
|
||
The reason why the XSS doesn't work with non-data-documents is that their script global object gets cleared. Because GlobalWindow doesn't know about data-documents, it can't clear anything in them.
Assignee | ||
Updated•16 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 9•16 years ago
|
||
Hmm, perhaps taking context (which has ok principal) from stack in case data document doesn't have scripthandlercontext would be good to prevent some possible regressions. Jst, any comments to that? It is not perfect solution, but would keep data documents usable even if the context for which they were created was lost.
Comment 10•16 years ago
|
||
XSS bugs are sg:high, sg:critical only if you can inject into a chrome frame (which allows arbitrary code execution) Olli's not expressing a lot of confidence in these patches, and we've got two similar bugs so there may be more in this area. Getting it right for 2.0.0.11 would be better than rushing these patches into 2.0.0.10
Flags: blocking1.8.1.10? → blocking1.8.1.11?
Whiteboard: [sg:critical] → [sg:high]
Updated•16 years ago
|
Flags: blocking1.8.1.11? → blocking1.8.1.11+
Assignee | ||
Comment 11•16 years ago
|
||
The patch should fix things, the problem is that it and bug 393762 disables some features - using event handlers with documents which are originally created in a different context.
Assignee | ||
Comment 12•16 years ago
|
||
Ok, I've done some testing in 1.8, and there event handling doesn't work (in normal cases) either with data or normal documents when their |window| has been teared down. ###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' property! is thrown there. That is good, we can expect and hope the fix here doesn't regress anything, and documents shouldn't IMO be used when their context isn't alive anymore. Note to myself, be careful when setting the event handling context.
Comment 13•16 years ago
|
||
Comment on attachment 288217 [details] [diff] [review] WIP Nothing better comes to mind. r+sr=jst
Attachment #288217 -
Flags: superreview?(jst)
Attachment #288217 -
Flags: superreview+
Attachment #288217 -
Flags: review?(jst)
Attachment #288217 -
Flags: review+
Assignee | ||
Updated•16 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Flags: in-testsuite?
Reporter | ||
Comment 14•16 years ago
|
||
Even when a different context is not used, onload event handlers can't be executed on documents which are originally created by DOMParser and XMLHttpRequest. Is this behavior intended?
Reporter | ||
Comment 15•16 years ago
|
||
fx-3.0b2pre-2007-11-15-05: DOMParser : onload event handler was called XMLHttpRequest : onload event handler was called createDocument : onload event handler was called fx-3.0b2pre-2007-11-16-05: DOMParser : --- XMLHttpRequest : --- createDocument : onload event handler was called
Assignee | ||
Comment 16•16 years ago
|
||
No, that is a regression. I'm fixing it. Thank you for testing!
Assignee | ||
Comment 17•16 years ago
|
||
Attachment #289147 -
Flags: superreview?(jst)
Attachment #289147 -
Flags: review?(jst)
Reporter | ||
Comment 18•16 years ago
|
||
Hmm, after applying the second patch, the first patch can be circumvented by using DOMParser or XMLHttpRequest on the subframe's context after loading a target site in the subframe.
Reporter | ||
Comment 19•16 years ago
|
||
This works with "ensure that inner window is used in data documents" patch applied.
Reporter | ||
Comment 20•16 years ago
|
||
This works with "ensure that inner window is used in data documents" patch applied.
Assignee | ||
Comment 21•16 years ago
|
||
When the latest XHR-XSS patch is applied, testcase 6 doesn't work. Now fixing testcase 5...
Assignee | ||
Comment 22•16 years ago
|
||
Comment on attachment 289147 [details] [diff] [review] ensure that inner window is used in data documents The patch to fix the callers are in the XHR-XSS bug.
Attachment #289147 -
Flags: superreview?(jst)
Attachment #289147 -
Flags: review?(jst)
Updated•16 years ago
|
Whiteboard: [sg:high] → [sg:high][need 1.8-branch patch]
Updated•16 years ago
|
Flags: wanted1.8.1.x+
Assignee | ||
Comment 23•16 years ago
|
||
The "WIP" patch for 1.8 is in Bug 393762.
Reporter | ||
Comment 24•16 years ago
|
||
Now, testcase 5 and 6 should work on current 1.8 branch build. On Windows XP, those work as expected, but on Linux, testcase 5 does not work due to the fact that subframe's document is still about:blank when calling DOMParser.parseFromString(). I'll attach a new version of testcase 5, which works both on Windows XP and Linux.
Reporter | ||
Comment 25•16 years ago
|
||
This works on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12pre) Gecko/20080125 BonEcho/2.0.0.12pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12pre) Gecko/20080125 BonEcho/2.0.0.12pre
Comment 26•16 years ago
|
||
Pushing this out into the next release.
Flags: blocking1.8.1.13+
Flags: blocking1.8.1.12-
Flags: blocking1.8.1.12+
Updated•16 years ago
|
Whiteboard: [sg:high][need 1.8-branch patch] → [sg:high][fixed by 403168]
Updated•16 years ago
|
Keywords: fixed1.8.1.13
Comment 27•16 years ago
|
||
I checked this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/2008031114 Firefox/2.0.0.13. For test cases 2, 3, and 4, the behavior is exactly the same between Firefox 2.0.0.12 and 2.0.0.13. There is no change. For test cases 5, 6, and 7, there is no alert with cookie information in Firefox 2.0.0.13, which I do see in Firefox 2.0.0.12. It isn't clear to me whether the behavior being the same for test cases 2, 3, and 4 means that this is only partially fixed. All I see in both versions in those cases is either the iframe with the page being displayed (and nothing else) or all three events being called.
Reporter | ||
Comment 28•16 years ago
|
||
The patch for 1.8 branch in bug 393762 comment #25 has included the first patch in this bug, thus testcase 1, 2 and 3 has been fixed in fx2.0.0.12. testcase 4 demonstrated a regression, which did not happen in fx2.0.0.12.
Comment 29•16 years ago
|
||
I see the same behavior with testcase 4 for both 2.0.0.12 and 2.0.0.13. Firefox 2.0.0.12 shows: DOMParser : onload event handler was called XMLHttpRequest : onload event handler was called createDocument : onload event handler was called Firefox 2.0.0.13 shows: DOMParser : onload event handler was called XMLHttpRequest : onload event handler was called createDocument : onload event handler was called
Reporter | ||
Comment 30•16 years ago
|
||
That is expected behavior. The regression happened only on trunk when the first patch in this bug landed.
Comment 31•16 years ago
|
||
Thanks! I've marked this as verified for 1.8.1.13.
Keywords: fixed1.8.1.13 → verified1.8.1.13
Updated•16 years ago
|
Flags: blocking1.8.0.15+
Updated•16 years ago
|
Group: security
Comment 32•16 years ago
|
||
how can i clone scriptGlobalObject in javascript or where i can read about scriptGlobalObject
Comment 33•16 years ago
|
||
What?
Comment 34•16 years ago
|
||
how can i create an XML document whose script handling object is a subframe's global object ?
Assignee | ||
Comment 35•16 years ago
|
||
frameElement.contentDocument.implementation.createDocument(...)
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•