2011234 - Extensions can dynamically execute code in their moz-extension: documents with tabs/scripting.executeScript

Status: RESOLVED FIXED

(WebExtensions :: General, defect, P1)

Description

[Rob Wu [:robwu]]

The tabs.executeScript and scripting.executeScript functions allow extensions to run arbitrary code (strings) in privileged extension contexts.

In Firefox 55, an attempt to call tabs.executeScript for a moz-extension: tab resulted in the following error:

Missing host permission for tab

The above is the intended behavior, confirmed in bug 1280801 (where a request for the ability to do so was closed as intentional), and this also matches Chrome's behavior (current behavior, but I also spot checked as far back as Chrome 40, released 11 years ago).

In Firefox 56 and later, execution succeeds, due to changes in bug 1271354, which added logic that unconditionally registers an extension's own URL as a granted permission (and the logic still exists). The original intent was for webRequest to allow matching of the URL (which does not even work - the unit test (test_chrome_ext_webrequest_mozextension.html) is always skipped), but the implementation enables content scripts to run in an extension's own origin as an unintended side effect.

But the ability to inject in one's own frames was explicitly declared as intentional in bug 1439012, and even documented at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/executeScript

This ability for extensions to trivially execute code in privileged extension contexts is at odds with other initiatives to avoid string-based code execution in extensions, such as the default CSP that restricts script-src to extension URLs, and even the removal of the ability to allowlist remote sources in MV3 (bug 1581608).

Comment 1

[Rob Wu [:robwu]]

Attachment: executeScript-in-extension.zip

STR:

1. Visit about:debugging and load the following extension. Or use web-ext run
2. Look at the page, which displays the result of calling tabs.executeScript with code location.href

Expected:

• Execution should fail. E.g. Firefox 56 shows Missing host permission for tab

Actual:

• Execution succeeds. The moz-extension:-URL is displayed.

Comment 2

[Rob Wu [:robwu]]

In bug 2004404, an extension encountered a bug because faster content script execution in about:blank, coupled with extension logic that called tabs.executeScript for the calling frame, caused a content script to execute in the moz-extension: document that the extension loaded in the tab. :vhilla asked whether this execution was intentional in https://bugzilla.mozilla.org/show_bug.cgi?id=2004404#c11 and noted that Chrome did not exhibit the same behavior.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1271354

:mixedpuppy, since you are the author of the regressor, bug 1271354, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Rob Wu [:robwu]]

(clearing needinfo, we will revisit this bug during the next triage meeting)

Comment 5

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 2011234 - Support restriction on content script moz-extension urls matching and enable restriction by default in Nightly. r=robwu!

Comment 6

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 2011234 - Test coverage for executeScript APIs on moz-extensions pages r=robwu!

Comment 7

[Daniel Veditz [:dveditz]]

"mitigation-bypass" in the sense that we have tried to prevent extensions from being able to "eval" strings in a more-than-web privileged context, as Rob noted at the end of comment 0

Comment 8

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 2011234 - Log a deprecation warning on content script injection into WebExtensions page or subframes. r?robwu!

Comment 9

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 2011234 - Collect emergency rollback pref in Glean telemetry probe. r?robwu!

Comment 10

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 2011234 - Collect Glean telemetry event on content script matching moz-extension documents. r?robwu!

Depends on D279865

Comment 11

[Donal Meehan [:dmeehan]]

This week is the final week of beta for Fx148.
:luca, do you think this will target a later release, or do you plan to land and request uplifts this week?

Comment 12

[Rob Wu [:robwu]]

We are planning to land a depreciation warning and let it ride the train, then flip the pref that enforces the new behavior by default.

I discussed this bug with Luca and dveditz and we agreed to open up the bug because the change in behavior will be obvious, and need to be documented.

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/2a23653e7c4e
https://hg.mozilla.org/integration/autoland/rev/4d5f28af1a2d
Support restriction on content script moz-extension urls matching and enable restriction by default in Nightly. r=robwu
https://github.com/mozilla-firefox/firefox/commit/508c9ea781b7
https://hg.mozilla.org/integration/autoland/rev/6fe6f431e418
Test coverage for executeScript APIs on moz-extensions pages r=robwu
https://github.com/mozilla-firefox/firefox/commit/eb46c1133614
https://hg.mozilla.org/integration/autoland/rev/cca2666ee322
Log a deprecation warning on content script injection into WebExtensions page or subframes. r=robwu
https://github.com/mozilla-firefox/firefox/commit/3d72fa8cd4a4
https://hg.mozilla.org/integration/autoland/rev/f214f66b343d
Collect emergency rollback pref in Glean telemetry probe. r=robwu
https://github.com/mozilla-firefox/firefox/commit/539c7f9ea52a
https://hg.mozilla.org/integration/autoland/rev/7decec007f35
Collect Glean telemetry event on content script matching moz-extension documents. r=robwu

Comment 14

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/4d5f28af1a2d
https://hg.mozilla.org/mozilla-central/rev/6fe6f431e418
https://hg.mozilla.org/mozilla-central/rev/cca2666ee322
https://hg.mozilla.org/mozilla-central/rev/f214f66b343d
https://hg.mozilla.org/mozilla-central/rev/7decec007f35

Comment 15

[Pascal Chevrel:pascalc]

Should we have a nightly-only 149 release note to announce this change?

Comment 16

[Rob Wu [:robwu]]

A release note on MDN only is sufficient.

dev-doc-needed keyword has already been added, we should mention the deprecation in 149 (warnings only on beta/release, enforced by default in Nightly) with the intent to enforce the restrictions by default on 152.

This affects tabs.executeScript, tabs.insertCSS, tabs.removeCSS, scripting.executeScript, scripting.insertCSS, scripting.removeCSS.

The tabs.executeScript documentation currently shows an example of execution in an extension page, that and the description should be modified: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/tabs/executeScript

There are also mentions of extensions getting host access to their own origin, in https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/permissions#host_permissions starting at

In Firefox, from version 56 onwards, extensions automatically get host permissions for their own origin, which is of the form:

... that needs to be removed/replaced. Similarly at https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/host_permissions

It does not require a special mention, because the default expectation is for a web page to be able to fetch() their own URLs, which also applies to extension documents. In the original first comment in the report here, I linked to some historical reason for the change - that has long been obsolete by now, so the only notable effect of the implicit permission was executeScript functionality, which we are deprecating with this bug.

Comment 17

[rbloor]

Doc updates in Bug-2011234: remove the ability to dynamically execute code in moz-extension:documents #43108

Comment 18

[Mr. Beedell, Roke Julian Lockhart (RJLB) [:RokeJulianLockhart]]

github.com/mbnuqw/sidebery/issues/2356#issuecomment-3932263746 explains a significant, negative downstream impact of this. I know of no alternative (although I am a lay person, in comparison to the ticket author).

Comment 19

[Rob Wu [:robwu]]

Thanks for sharing RJLB. I wrote a reply at https://github.com/mbnuqw/sidebery/issues/2356#issuecomment-3940917522 . The short version is that I do see alternatives, except possibly for one case: arbitrary code execution. Perhaps we should consider prioritizing the implementation of bug 1685123 as a mitigation.

Comment 20

[Daniel Veditz [:dveditz]]

Even though this bug report is fixed, the protection is not enabled for release yet. See bug 2015559