Closed Bug 1845739 (CVE-2023-5725) Opened 11 months ago Closed 10 months ago

WebExtension can open Internal pages using windows.create

Categories

(WebExtensions :: General, defect, P2)

defect

Tracking

(firefox-esr102 unaffected, firefox-esr115119+ fixed, firefox115 wontfix, firefox116 wontfix, firefox117 wontfix, firefox118 wontfix, firefox119+ fixed)

VERIFIED FIXED
119 Branch
Tracking Status
firefox-esr102 --- unaffected
firefox-esr115 119+ fixed
firefox115 --- wontfix
firefox116 --- wontfix
firefox117 --- wontfix
firefox118 --- wontfix
firefox119 + fixed

People

(Reporter: fazim.pentester, Assigned: robwu)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, reporter-external, sec-moderate, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main119+][adv-ESR115.4+])

Attachments

(8 files)

Attached file 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.
Flags: sec-bounty?
Attached video demo.mp4
Component: Security → General
Product: Firefox → WebExtensions

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

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?

Attached image 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.

Attached video 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.

Attached file exploit.zip
Summary: WebExtension can open Privileged pages using windows.open → WebExtension can open Internal pages using windows.open
Summary: WebExtension can open Internal pages using windows.open → WebExtension can open Internal pages using windows.create

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

I'll fix this.

Assignee: nobody → rob
Severity: -- → S3
Status: NEW → ASSIGNED
Keywords: regression
Priority: -- → P2
Regressed by: 1711168

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

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

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.

Blocks: 1835484

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
Attachment #9348836 - Flags: sec-approval?
Keywords: sec-moderate

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.

Attachment #9348836 - Flags: sec-approval? → sec-approval+
Attachment #9348837 - Flags: sec-approval+

We should land this on ESR 115 as well

Pushed by rob@robwu.nl:
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
Group: firefox-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → 119 Branch

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.
Attachment #9348836 - Flags: approval-mozilla-esr115?
Attachment #9348837 - Flags: approval-mozilla-esr115?

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

Flags: needinfo?(rob)

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.

Flags: needinfo?(rob)

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: :)

Flags: needinfo?(rob)
Flags: sec-bounty? → sec-bounty+

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.

Duplicate of this bug: 1845735

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.

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

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

(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.

Blocks: 1851824
Flags: needinfo?(rob)
No longer duplicate of this bug: 1845735

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

Approved for 115.4esr

Attachment #9348836 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+
Attachment #9348837 - Flags: approval-mozilla-esr115? → approval-mozilla-esr115+
QA Whiteboard: [post-critsmash-triage]
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][adv-main119+]
Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main119+] → [reporter-external] [client-bounty-form] [verif?][adv-main119+][adv-ESR115.4+]
Attached file advisory.txt
Alias: CVE-2023-5725

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

Group: core-security-release
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: