XSS by using XMLDocument.load() and event handler

RESOLVED FIXED

Status

()

Core
DOM
P2
normal
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: moz_bug_r_a4, Assigned: smaug)

Tracking

({verified1.8.1.13})

unspecified
x86
Windows XP
verified1.8.1.13
Points:
---
Bug Flags:
blocking1.9 +
blocking1.8.1.12 -
blocking1.8.1.13 +
wanted1.8.1.x +
blocking1.8.0.next +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:high][fixed by 403168])

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
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

10 years ago
Created attachment 287963 [details]
testcase 1 - DOMImplementation.createDocument()

This tries to get cookies for www.mozilla.com.
This works on trunk.
(Reporter)

Comment 2

10 years ago
Created attachment 287964 [details]
testcase 2 - DOMParser.parseFromString()

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

10 years ago
Created attachment 287965 [details]
testcase 3 - XMLHttpRequest.responseXML

This tries to get cookies for www.mozilla.com.
This works on trunk.
Flags: blocking1.8.1.10?
Whiteboard: [sg:critical]
Assignee: dveditz → nobody
Component: Security → DOM
QA Contact: toolkit → general
Flags: blocking1.9?
(Assignee)

Updated

10 years ago
Assignee: nobody → Olli.Pettay
(Assignee)

Comment 4

10 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

10 years ago
Flags: blocking1.9? → blocking1.9+
Priority: -- → P2
(Assignee)

Comment 5

10 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

10 years ago
Created attachment 288217 [details] [diff] [review]
WIP

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

10 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

10 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

10 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 9

10 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.
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]
Flags: blocking1.8.1.11? → blocking1.8.1.11+
(Assignee)

Comment 11

10 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

10 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 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

10 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Flags: in-testsuite?
(Reporter)

Comment 14

10 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

10 years ago
Created attachment 289131 [details]
testcase 4

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

10 years ago
No, that is a regression. I'm fixing it.
Thank you for testing!
(Assignee)

Comment 17

10 years ago
Created attachment 289147 [details] [diff] [review]
ensure that inner window is used in data documents
Attachment #289147 - Flags: superreview?(jst)
Attachment #289147 - Flags: review?(jst)
(Reporter)

Comment 18

10 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

10 years ago
Created attachment 289277 [details]
testcase 5 - DOMParser.parseFromString()

This works with "ensure that inner window is used in data documents" patch
applied.
(Reporter)

Comment 20

10 years ago
Created attachment 289278 [details]
testcase 6 - XMLHttpRequest.responseXML

This works with "ensure that inner window is used in data documents" patch
applied.
(Assignee)

Comment 21

10 years ago
When the latest XHR-XSS patch is applied, testcase 6 doesn't work.
Now fixing testcase 5...
(Assignee)

Comment 22

10 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)
Whiteboard: [sg:high] → [sg:high][need 1.8-branch patch]
Flags: wanted1.8.1.x+
(Assignee)

Comment 23

10 years ago
The "WIP" patch for 1.8 is in Bug 393762.
(Reporter)

Comment 24

10 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

10 years ago
Created attachment 299206 [details]
testcase 7 (testcase 5 for 1.8 branch on Linux) - DOMParser.parseFromString()

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
Pushing this out into the next release.
Flags: blocking1.8.1.13+
Flags: blocking1.8.1.12-
Flags: blocking1.8.1.12+
Whiteboard: [sg:high][need 1.8-branch patch] → [sg:high][fixed by 403168]
Keywords: fixed1.8.1.13
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

10 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.
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

10 years ago
That is expected behavior.  The regression happened only on trunk when the
first patch in this bug landed.
Thanks!

I've marked this as verified for 1.8.1.13.
Keywords: fixed1.8.1.13 → verified1.8.1.13

Updated

10 years ago
Flags: blocking1.8.0.15+
Group: security

Comment 32

10 years ago
how can i clone scriptGlobalObject in javascript or where i can read about scriptGlobalObject
What?

Comment 34

10 years ago
how can i create an XML document whose script handling object is a subframe's
global object ?
(Assignee)

Comment 35

10 years ago
frameElement.contentDocument.implementation.createDocument(...)
You need to log in before you can comment on or make changes to this bug.