XrayResolveOwnProperty doesn't check if we're chrome before invoking XrayResolveUnforgeableProperty with nativeProperties.chromeOnly

RESOLVED FIXED

Status

()

defect
RESOLVED FIXED
5 years ago
3 months ago

People

(Reporter: bholley, Unassigned)

Tracking

({sec-other})

unspecified
x86
macOS
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr31 unaffected)

Details

Reporter

Description

5 years ago
I just came across http://hg.mozilla.org/mozilla-central/file/641d450532be/dom/bindings/BindingUtils.cpp#l1013 , which looks bad to me at first glance. Am I missing something?
Reporter

Updated

5 years ago
Flags: needinfo?(peterv)
Should be fine for now, we don't have unforgeable chrome-only APIs.
Flags: needinfo?(peterv)
I think I keep assuming Xrays means chrome... which it does, except for Location and Window.

I agree, this should be fixed.
Reporter

Comment 3

5 years ago
(In reply to Boris Zbarsky [:bz] from comment #2)
> I think I keep assuming Xrays means chrome... which it does, except for
> Location and Window.

No, that's not the issue - the issue is same-origin Xrays (wantXrays) and nsExpandedPrincipal, neither of which should have access to chrome-only APIs.
Oh, sandboxes, right.  :(
Reporter

Comment 5

5 years ago
Looks like peter's patch in bug 787070 fixes this. We should verify once that lands.
Depends on: 787070
Reporter

Updated

5 years ago
Keywords: sec-other
Reporter

Comment 6

5 years ago
This was fixed by bug 787070.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

Updated

4 years ago
Group: core-security → core-security-release
Group: core-security-release
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.