Closed Bug 1486738 Opened 7 years ago Closed 7 years ago

Tabs created through browser.windows.create are not associated with the extension's principal

Categories

(WebExtensions :: Frontend, defect, P1)

defect

Tracking

(firefox-esr60 wontfix, firefox62 wontfix, firefox63 wontfix, firefox64 fixed)

RESOLVED FIXED
mozilla64
Tracking Status
firefox-esr60 --- wontfix
firefox62 --- wontfix
firefox63 --- wontfix
firefox64 --- fixed

People

(Reporter: robwu, Assigned: robwu)

References

(Blocks 1 open bug)

Details

(Keywords: sec-audit, Whiteboard: [post-critsmash-triage][adv-main64-])

In the tabs.create API, we put efforts in associating extension-created tabs with the extension's principal: https://searchfox.org/mozilla-central/rev/55da592d85c2baf8d8818010c41d9738c97013d2/browser/components/extensions/parent/ext-tabs.js#567-584 But in windows.create, this logic is completely absent. https://searchfox.org/mozilla-central/rev/55da592d85c2baf8d8818010c41d9738c97013d2/browser/components/extensions/parent/ext-windows.js#164-176,200-201 Both tabs.create and windows.create do already validate their URLs, so this is probably not that severe. But here is an example of how the absence of the logic can result in a bypass: In Firefox Nightly, extensions cannot open file:-URLs in new tabs. This is a bug or feature, depending on the outcome of bug 1485778. For STR, see: https://bugzilla.mozilla.org/show_bug.cgi?id=1485778#c12 If we replace tabs.create with windows.create in the linked STR, then a local file is opened in a new window, even though this was disallowed in the tabs.create API. We should unify the principal logic for the tabs.create and windows.create APIs.
Annoyingly I don't think we can pass individual principals here to match the same code as tabs. Also this seems to call OpenWindowInternal which sometimes uses a subjectPrincipal as the triggeringPrincipal. I think this probably explains my errors with trying to lock down loadURI to require a triggeringPrincipal.
Pretty sure there's already a bug for this, but I can't find it.
Priority: -- → P1
Assigning to Rob because this should be a small fix. Shane looked at a possible solution for this already.
Assignee: nobody → rob
I think we should just add the triggeringPrincipal to the window args, I don't think a refactor to try and make this work with tabs.create is going to be any use.
notes from irc: The args array[2] given to ww.openWindow can take an nsIPrincipal object for the triggeringPrincipal. It should be used from browser.js[1]. Might as well also include the userContextId at the same time. [1] https://searchfox.org/mozilla-central/rev/2fe43133dbc774dda668d4597174d73e3969181a/browser/base/content/browser.js#1658 [2] https://searchfox.org/mozilla-central/rev/05d91d3e02a0780f44599371005591d7988e2809/browser/components/extensions/parent/ext-windows.js#139
See Also: → CVE-2018-18497
FIxed by bug 1393570.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla64
Group: toolkit-core-security → core-security-release
Flags: qe-verify-
Whiteboard: [post-critsmash-triage]
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main64-]
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.