Closed Bug 635776 Opened 11 years ago Closed 10 years ago

When Javascript stack space is limited, returns a ChromeWindow


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

Not set



Tracking Status
status1.9.2 --- unaffected
status1.9.1 --- unaffected


(Reporter: zrhoffman, Assigned: smaug)


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


(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 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
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".
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
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]

Attachment #516280 - Flags: review?(bzbarsky) → review+
Attachment #516280 - Flags: approval2.0?
Attachment #516280 - Flags: approval2.0? → approval2.0+
Checked in:
Closed: 10 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.