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.
Created attachment 287963 [details] testcase 1 - DOMImplementation.createDocument() This tries to get cookies for www.mozilla.com. This works on trunk.
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).
Created attachment 287965 [details] testcase 3 - XMLHttpRequest.responseXML This tries to get cookies for www.mozilla.com. This works on trunk.
Assignee: dveditz → nobody
Component: Security → DOM
QA Contact: toolkit → general
Assignee: nobody → Olli.Pettay
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.
(In reply to comment #4) > not just alerts using data from iframe. nevermind, idiot me. Jst clarified this in Bug 403168
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.)
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.
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 184.108.40.206 would be better than rushing these patches into 220.127.116.11
Flags: blocking18.104.22.168? → blocking22.214.171.124?
Whiteboard: [sg:critical] → [sg:high]
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.
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
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
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?
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
No, that is a regression. I'm fixing it. Thank you for testing!
Created attachment 289147 [details] [diff] [review] ensure that inner window is used in data documents
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.
Created attachment 289277 [details] testcase 5 - DOMParser.parseFromString() This works with "ensure that inner window is used in data documents" patch applied.
Created attachment 289278 [details] testcase 6 - XMLHttpRequest.responseXML This works with "ensure that inner window is used in data documents" patch applied.
When the latest XHR-XSS patch is applied, testcase 6 doesn't work. Now fixing testcase 5...
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.
Whiteboard: [sg:high] → [sg:high][need 1.8-branch patch]
The "WIP" patch for 1.8 is in Bug 393762.
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.
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:126.96.36.199pre) Gecko/20080125 BonEcho/188.8.131.52pre Mozilla/5.0 (X11; U; Linux i686; en-US; rv:184.108.40.206pre) Gecko/20080125 BonEcho/220.127.116.11pre
Pushing this out into the next release.
Whiteboard: [sg:high][need 1.8-branch patch] → [sg:high][fixed by 403168]
I checked this in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/2008031114 Firefox/22.214.171.124. For test cases 2, 3, and 4, the behavior is exactly the same between Firefox 126.96.36.199 and 188.8.131.52. There is no change. For test cases 5, 6, and 7, there is no alert with cookie information in Firefox 184.108.40.206, which I do see in Firefox 220.127.116.11. 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.
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 fx18.104.22.168. testcase 4 demonstrated a regression, which did not happen in fx22.214.171.124.
I see the same behavior with testcase 4 for both 126.96.36.199 and 188.8.131.52. Firefox 184.108.40.206 shows: DOMParser : onload event handler was called XMLHttpRequest : onload event handler was called createDocument : onload event handler was called Firefox 220.127.116.11 shows: DOMParser : onload event handler was called XMLHttpRequest : onload event handler was called createDocument : onload event handler was called
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 18.104.22.168.
Keywords: fixed22.214.171.124 → verified126.96.36.199
how can i create an XML document whose script handling object is a subframe's global object ?
You need to log in before you can comment on or make changes to this bug.