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)
WebExtensions
Frontend
Tracking
(firefox-esr60 wontfix, firefox62 wontfix, firefox63 wontfix, firefox64 fixed)
RESOLVED
FIXED
mozilla64
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.
Comment 1•7 years ago
|
||
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.
Updated•7 years ago
|
Blocks: require-triggering-principal
Comment 2•7 years ago
|
||
Pretty sure there's already a bug for this, but I can't find it.
Updated•7 years ago
|
Priority: -- → P1
Comment 3•7 years ago
|
||
Assigning to Rob because this should be a small fix. Shane looked at a possible solution for this already.
Assignee: nobody → rob
Comment 4•7 years ago
|
||
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.
Comment 5•7 years ago
|
||
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
| Assignee | ||
Updated•7 years ago
|
See Also: → CVE-2018-18497
| Assignee | ||
Comment 6•7 years ago
|
||
FIxed by bug 1393570.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Updated•7 years ago
|
status-firefox62:
--- → wontfix
status-firefox63:
--- → wontfix
status-firefox64:
--- → fixed
status-firefox-esr60:
--- → wontfix
Target Milestone: --- → mozilla64
Updated•7 years ago
|
Group: toolkit-core-security → core-security-release
Updated•7 years ago
|
Flags: qe-verify-
Whiteboard: [post-critsmash-triage]
Updated•7 years ago
|
Whiteboard: [post-critsmash-triage] → [post-critsmash-triage][adv-main64-]
Updated•6 years ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•