Closed Bug 393761 Opened 17 years ago Closed 17 years ago

XSS and Arbitrary code execution by using XMLDocument.load() and event handler

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: moz_bug_r_a4, Assigned: smaug)

References

Details

(Keywords: verified1.8.1.12, Whiteboard: [sg:critical] fixed by bug 393762) 

This is related to bug 382636 and bug 325818.

XSS:
1. Create an XML document (D) with a subframe's context, 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.

Arbitrary code execution:
1. Create an XML document (D) by using XMLDocument.cloneNode(), and attach an
   onload event handler to D.
2. Call D.load().

The onload event handler is called with the hidden window's principal.  Since
the hidden window's principal is allowed to load chrome: urls, it's possible to
run arbitrary code with chrome privileges by using an XSS attack.
Attached file testcase 1 - XSS — 
This tries to get cookies for www.mozilla.com.
This works on trunk, fx2.0.0.x, fx1.5.0.x, sm-trunk, sm1.1.x and sm1.0.x.
This works on trunk, fx2.0.0.x, fx1.5.0.x, sm-trunk, sm1.1.x and sm1.0.x.
Assignee: dveditz → jst
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.9?
Whiteboard: [sg:critical]
I have some code (for Bug 382636), which may fix this one too. I'll test...
Taking
Assignee: jst → Olli.Pettay
Flags: blocking1.9? → blocking1.9+
Status: NEW → ASSIGNED
Smaug, did you manage to fix this?
The fix is in Bug 393762
Depends on: 393762
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
I'd like the XSS testcase to also end up in the testsuite and get verified, I think it's better to say this one is "fixed by" the other bug than to mark it duplicate. At least for security bugs since we want to be extra careful things get verified and don't regress.
Status: RESOLVED → REOPENED
Flags: in-testsuite?
Resolution: DUPLICATE → ---
Whiteboard: [sg:critical] → [sg:critical] fixed by bug 393762
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
Flags: blocking1.8.1.11+
Flags: blocking1.8.1.10?
Flags: blocking1.8.1.10?
Verified using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b2pre) Gecko/2007121107 Minefield/3.0b2pre
Status: RESOLVED → VERIFIED
should be fixed by bug 393762, but needs to be verified that that is as true on branch as it was on trunk.
Keywords: fixed1.8.1.12
Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.12) Gecko/2008012822 Firefox/2.0.0.12:

No alert with cookie information for test case 1 (seen in 2.0.0.11).

Test case 2 does not visibly do anything in either 2.0.0.11 or 2.0.0.12rc1. 

I notice that the error console when running test case 2 shows the following in 2.0.0.11:

Security Error: Content at https://bugzilla.mozilla.org/attachment.cgi?ie=278296 may not load or link to resource://gre/res/hiddenWindow.html.
With a clean profile, using Firefox 2.0.0.11:
  * testcase 1 shows an iframe with mozilla.com in it and displays my cookie in a dialog.
  * testcase 2 shows an iframe with about:mozilla in it and displays a dialog that has "Components.stack" in it.

With a clean profile, using Firefox 2.0.0.12 RC1 I don't see either of those things. The iframe in testcase 1 shows mozilla.com but does not display my cookie or any dialog. The iframe in testcase 2 is empty and the dialog does not appear.

I'm verifying this, but Al, if you can confirm your comment 11 is true, please comment and set this back to fixed.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/2008012820 Firefox/2.0.0.12
Keywords: fixed1.8.1.12 → verified1.8.1.12
This is Windows only, at least for test case 2. (Test case 1 displays the bug in 2.0.0.11 but not in 2.0.0.12 on the Mac so that part of the exploit does work on a Mac in 2.0.0.11).

I tested this on Windows XP with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.11) Gecko/2007112718 Firefox/2.0.0.11 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.12) Gecko/2008012820 Firefox/2.0.0.12 and I see the same thing as Sam. This is fixed in 2.0.0.12.
It turns out that this is Linux as well. I've verified the bug on 2.0.0.11. 

I reverified the fix with the rc2 build of Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.12) Gecko/2008013015 Firefox/2.0.0.12.
Group: security
Is there any working patch?
The patch should be in bug 393762 - that's where this issue has been fixed.
I created xmlDocument, appended an iframe and onload event, but after load(''); iframe dissapered.What was my mistake? 
before load : http://keep4u.ru/imgs/b/080612/de/de7b34c618c06787b6.jpg
after load : http://keep4u.ru/imgs/b/080612/5f/5f721bd97ccabf0dc8.jpg
You need to log in before you can comment on or make changes to this bug.