Closed Bug 635776 Opened 9 years ago Closed 9 years ago

When Javascript stack space is limited, window.open() returns a ChromeWindow

Categories

(Core :: DOM: Core & HTML, defect, critical)

x86
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla2.0
Tracking Status
status1.9.2 --- unaffected
status1.9.1 --- unaffected

People

(Reporter: zrhoffman, Assigned: smaug)

Details

(Keywords: regression, Whiteboard: [sg:high])

Attachments

(3 files)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b11) Gecko/20100101 Firefox/4.0b11

If enough stack space is exhausted when window.open() is called, the new window's initialization fails in fundamental ways (it has no visual components besides the bare window and is not loaded as a tab), though the function manages to return a ChromeWindow reference.  The opener window then has full read/write access to the ChromeWindow's document object, regardless of either's page location.



Reproducible: Always

Steps to Reproduce:
1. Open Firefox beta 11 (or possibly other beta versions)
2. Run either the testcase (attached), or the following code from the address bar:
(function g(){try{eval("g()")}catch(c){if(c!=2)throw c[0]?1:c+1;d=open('data:text/html,A page')}})()



After running the testcase, the error console contains new exceptions after subsequent pageloads, sometimes even after restarting the browser.
I can't reproduce on 64bit Linux, but "Open a ChromeWindow" does cause a crash.
Blake, care to have a look? We should never return the outer chrome window from window.open()...
Assignee: nobody → mrbkap
Whiteboard: [sg:high]
Tried injecting "try{alert(Components.stack)} catch(e){alert(e)}" and got a security exception, proving it's not Chrome-privileged despite being a "ChromeWindow".
Status: UNCONFIRMED → NEW
Ever confirmed: true
When I try to inject "alert(Components.stack)" instead I get a security exception in the error console.  This implies the window does not actually have chrome privileges.  Still XSS though.
Is this a regression?
There were some changes to window handling for FF4.
Ok, at least on 64bit linux / debug build this is a regression from
1.9.2.
Keywords: regression
Both 1.9.2 and 1.9.1 give security error when trying to inject code.
Assignee: mrbkap → Olli.Pettay
Attachment #515915 - Flags: review?(bzbarsky)
Attachment #515915 - Flags: review?(jst)
I haven't run tests yet.
Hmm.  So why does JS stack space matter?  We fail to get newWindow because of OOM or something?
Well all sort of things start to fail if we're running out of
JS stack space when creating a new window. The js in the new window
just can't run properly.
But I can still debug some more to find the exact place which prevents
the created window to have primary content shell.
Actually, might be better to add a check to nsXULWindow::CreateNewContentWindow
that the primary content shell can be get from the result.
That seems like a good sanity-check, yes.  I'm not that interested in where the window creation fails, as long as it fails.  ;)
Apparently comment 14 isn't enough to fix this bug. Debugging...
Attached patch patchSplinter Review
Idiot me, I was checking mPrimaryContentShell of wrong XULWindow :)
This should work.

Posted to tryserver.
Attachment #516280 - Flags: review?(bzbarsky)
Attachment #515915 - Flags: review?(jst)
Attachment #515915 - Flags: review?(bzbarsky)
Comment on attachment 516280 [details] [diff] [review]
patch

r=me
Attachment #516280 - Flags: review?(bzbarsky) → review+
Attachment #516280 - Flags: approval2.0?
Attachment #516280 - Flags: approval2.0? → approval2.0+
Checked in:

http://hg.mozilla.org/mozilla-central/rev/e79b2b60d394
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0
Group: core-security
Flags: sec-bounty+
You need to log in before you can comment on or make changes to this bug.