1845739 - (CVE-2023-5725) WebExtension can open Internal pages using windows.create

Status: VERIFIED FIXED

(WebExtensions :: General, defect, P2)

Description

[Shaheen Fazim]

Attachment: poc.zip

Using the browser.windows.open() function, a malicious WebExtension can open privileged pages like addons, about, etc., without any restrictions.

Steps to Reproduce:

1. Download and extract poc.zip to a folder
2. Open the Firefox browser and load the extracted files as WebExtention about:debugging#/runtime/this-firefox to begin testing.

Comment 1

[Shaheen Fazim]

Attachment: demo.mp4

Comment 2

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

Technically the behavior shown in the proof of concept looks like the currently intended behavior based on the changes applied from Bug 1711168:

• when windows.create is called with only one url, the internals can determine if the url cannot be opened with the extension principal as the triggering url and an appropriate triggering principal should be computed based on the target url (with the logic computing the triggeringPrincipal coming from https://searchfox.org/mozilla-central/rev/00e6644d0db8acf9372702324151b8077a3d2bb7/browser/components/extensions/parent/ext-windows.js#149-167)

• when windows.create is called with more than one urls, then the call is rejected if the extension principal is not allowed to access some of the urls passed (and the call gets rejected with a Illegal URL... exception)

The extensions would still be unable to access the content of the tab loading an "about:" url that it is not allowed to access, e.g. they are not allowed to inject scripts into that tab, and if I recall correctly the current behavior was chosen to allow existing (non malicious) extensions to still work after we have introduced more restrictions related to loading non web accessible moz-extension urls from other enabled extensions (in particular "windows / tabs manager" extensions).

The poc attached doesn't seem to be demonstrating an actual exploit in the current form (unless I'm misreading it), is it something achievable by combining this (currently expected) behavior with other issues?

Comment 3

[Shaheen Fazim]

Attachment: console.png

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #2)

The extensions would still be unable to access the content of the tab loading an "about:" url that it is not allowed to access, e.g. they are not allowed to inject scripts into that tab

Yes, after loading the about: URL, it is not possible to inject a script there, making it non-vulnerable in that case. However, even though I cannot inject a script, I can still log the window object (I am not sure of the security impact). This object provides access to various properties, datatype variables and methods related to the current browsing context.

Comment 4

[Shaheen Fazim]

Attachment: exploit-demo.mp4

(In reply to Luca Greco [:rpl] [:luca] [:lgreco] from comment #2)

The poc attached doesn't seem to be demonstrating an actual exploit in the current form (unless I'm misreading it), is it something achievable by combining this (currently expected) behavior with other issues?

Thank you for suggesting combining different methods. I tried using the captureVisibleTab API, and it is possible to capture screenshots of privileged pages of the victim and send them to the attacker as image data.

Comment 5

[Shaheen Fazim]

Attachment: exploit.zip

Comment 6

[Rob Wu [:robwu]]

This is a regression caused by https://hg.mozilla.org/mozilla-central/rev/d0da1be14163.

I'll fix this.

Comment 7

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

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

Comment 8

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

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

Comment 9

[Rob Wu [:robwu]]

Attachment: Bug 1845739 - windows.create consistent with tabs.create

This also fixes bug 1835484

Comment 10

[Rob Wu [:robwu]]

Attachment: Bug 1845739 - About test case in browser_ext_windows_create_url.js

This also refactors the test to improve its reliability and clarity.
Previously, the "fail" test cases ran after the test signaled completion
of the test, which means that it wasn't reliable at detecting expected
failures.

Comment 11

[Rob Wu [:robwu]]

Comment on attachment 9348836 [details]
Bug 1845739 - windows.create consistent with tabs.create

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Not easily. The ability to open arbitrary URLs in itself is not an immediate security issue, but combined with other vulnerabilities it can be.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which older supported branches are affected by this flaw?: all
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: No
• If not, how different, hard to create, and risky will they be?: Should apply easily.
• How likely is this patch to cause regressions; how much testing does it need?: Not likely; covered by unit tests. Extensions that relied on the original undocumented behavior could unexpectedly break, but that is a necessary change to fix the security issue.
• Is Android affected?: No

Comment 12

[Daniel Veditz [:dveditz]]

Comment on attachment 9348836 [details]
Bug 1845739 - windows.create consistent with tabs.create

sec-approval+ = dveditz

The testcase is fine to land with the patch.

Comment 13

[Daniel Veditz [:dveditz]]

We should land this on ESR 115 as well

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/aeee2a248682
windows.create consistent with tabs.create r=zombie
https://hg.mozilla.org/integration/autoland/rev/bd48139a6966
About test case in browser_ext_windows_create_url.js r=zombie

Comment 15

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/aeee2a248682
https://hg.mozilla.org/mozilla-central/rev/bd48139a6966

Comment 16

[Rob Wu [:robwu]]

Comment on attachment 9348836 [details]
Bug 1845739 - windows.create consistent with tabs.create

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Fix for security bug.
• User impact if declined: Extensions can open URLs that are restricted otherwise.
• Fix Landed on Version: 119
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The risk is a bit more than none, because it breaks extensions that try to rely on it to open many URLs (e.g. bookmarks) at once with this mechanism AND when they expect privileged URLs to be loadable in this way. This ability to open arbitrary URLs is however unintentional and not documented, and an intentional behavioral change.

Comment 17

[Donal Meehan [:dmeehan]]

:robwu could you add beta uplift requests here also?
This grafts cleanly to beta

Comment 18

[Rob Wu [:robwu]]

This is not a recent regression, so I'm inclined to let it ride the trains in case there are add-ons that relied on the behavior.

Comment 19

[Frederik Braun [:freddy]]

Rob, can you please file a follow-up to write tests that enumerate our about: URLs and makes sure that none of them work. A chrome:/ and resource:/ and file: :)

Comment 20

[Shaheen Fazim]

Hello, I have reported a separate issue regarding the "file://" URI where an attacker can leak arbitrary files by injecting JavaScript into the "file://" URI. If that report turns out to be a duplicate of this one, as Daniel mentioned, could you please elevate the security level to "high" due to the different methods of exploitation that an attacker can achieve using various URIs from an extension? Thank you.

Comment 22

[Daniel Veditz [:dveditz]]

Our ratings for Web Extensions are capped to "sec-moderate" because of limited reach: you have to convince people to install an extension (which is already dangerous, even if working as intended), and if the malware spreads it will be discovered and killed. "Sec-high" web page issues, in contrast, can affect all the millions of Firefox users if you can inject the code into a popular site or into an ad network, and even asking someone to click a link is a lower hurdle than installing an extension.

Comment 23

[Shaheen Fazim]

Thank you for clarifying, and thanks for the quick fix and bounty 😄.

Comment 24

[Shaheen Fazim]

If possible, please mention both of these exploits in the advisory. Thank you.

Comment 25

[Rob Wu [:robwu]]

(In reply to Frederik Braun [:freddy] from comment #19)

Rob, can you please file a follow-up to write tests that enumerate our about: URLs and makes sure that none of them work. A chrome:/ and resource:/ and file: :)

Filed bug 1851824.

Comment 26

[Dianna Smith [:diannaS]]

Comment on attachment 9348836 [details]
Bug 1845739 - windows.create consistent with tabs.create

Approved for 115.4esr

Comment 27

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/a1167276b906
https://hg.mozilla.org/releases/mozilla-esr115/rev/16ab4d61519a

Comment 28

[Tyson Smith [:tsmith]]

Attachment: advisory.txt

Comment 29

[Daniel Veditz [:dveditz]]

Bulk-unhiding security bugs fixed in Firefox 119-121 (Fall 2023). Use "moo-doctrine-subsidy" to filter