Closed
Bug 829310
Opened 12 years ago
Closed 12 years ago
compartment mismatch in nsWindowSH::NewResolve for dialogArguments with Xrays
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
People
(Reporter: mccr8, Assigned: mccr8)
References
Details
(Keywords: sec-audit)
Found by inspection in bug 826471: "The chunk of code in nsWindowSH::NewResolve for sDialogArguments_id also looks sketchy to me. It grabs the argument object off of the window, then uses the window's context to set a property on obj, which in this Xray case is not in the same compartment as the window, I believe. nsJSContext::SetProperty does an XPCAutoRequest, but doesn't enter a compartment anywhere as far as I can see."
I've tried writing a testcase, but I haven't managed to yet. dialogArguments is apparently only present with showModalDialog.
Assignee | ||
Comment 1•12 years ago
|
||
I don't know how exploitable this actually is. It is pretty old code.
status-b2g18:
--- → affected
status-firefox18:
--- → wontfix
status-firefox19:
--- → affected
status-firefox20:
--- → affected
status-firefox21:
--- → affected
status-firefox-esr17:
--- → affected
Assignee | ||
Updated•12 years ago
|
Comment 2•12 years ago
|
||
Can web content affect the dialog arguments, or is this only a problem for privileged code?
tracking-firefox20:
--- → +
tracking-firefox21:
--- → +
Assignee | ||
Comment 3•12 years ago
|
||
I think it can choose what it is, but this only is a problem when Xrays are involved, and maybe those are only from privileged code? I haven't seen any crashes with this in the wild, so maybe it is not common for addons to touch this.
Comment 4•12 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #3)
> I think it can choose what it is, but this only is a problem when Xrays are
> involved, and maybe those are only from privileged code?
Unprivileged scopes get Xrays to non-same-origin content, and can also create xrays via Components.lookupMethod.
Comment 5•12 years ago
|
||
Batch edit: Bugs marked status-b2g18: affected after 2/13 branching of v1.0.1 are now also status-b2g18-v1.0.1: affected
status-b2g18-v1.0.1:
--- → affected
Updated•12 years ago
|
status-firefox22:
--- → affected
tracking-firefox22:
--- → +
Comment 6•12 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #1)
> I don't know how exploitable this actually is. It is pretty old code.
Why track this for release if the sec-critical rating is only theoretical right now? We should consider completing an investigation and finding a testcase prior to tracking.
Updated•12 years ago
|
status-firefox23:
--- → affected
tracking-firefox23:
--- → +
Assignee | ||
Comment 7•12 years ago
|
||
It isn't clear that there's actually a problem here, and bholley is rewriting this, so I'm just going to downgrade it.
Keywords: sec-critical → sec-audit
Assignee | ||
Comment 8•12 years ago
|
||
Bobby, do you think this is okay to close now? I don't know if this is part of the code that you rewrote or not.
Comment 9•12 years ago
|
||
Yeah, it all goes through IDL now.
Assignee | ||
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Updated•12 years ago
|
Updated•9 years ago
|
Group: core-security → core-security-release
Updated•9 years ago
|
Keywords: testcase-wanted
Updated•7 years ago
|
Group: core-security-release
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
Updated•3 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•