1744158 - (CVE-2022-22739) Security: Background page using iframe can show external protocol dialog in other tabs and without throttling

Status: VERIFIED FIXED

(Core :: DOM: Security, task)

Description

[Alesandro Ortiz]

Attachment: spoof-calc-diff-tab.html

This is a standalone bug for Scenario 5 reported in bug 1705211. I didn't previously report separately since I thought this would be fixed in that bug. I assumed that fixing origin display would fix dialog<->tab association, but seems dialog isn't properly associated with the tab in even with fix when using iframes.

When a background page navigates an iframe to an external protocol URL, the external protocol dialog is shown on the currently focused tab. The dialog will repeatedly be shown on the currently focused tab and any other tab if the user switches tabs.

Firefox behaves as expected when a background page navigates itself (whole tab) to an external protocol URL. This issue only seems to occur when the background page performs the navigation using an iframe.

After the fix for bug 1705211, the dialog shows the correct origin (https://aogarantiza.com in this case). However, since there's no throttling or user activation requirement, a user can still feel pressured to proceed with the dialog or potentially think the dialog is mistaken about the origin or that it's coming from the browser itself due to the persistence and cross-tab presence. The dialog will keep re-appearing until the user closes the malicious tab, which could be any other tab.

REPRODUCTION CASE
One way to repro is to use Scenario 5's PoC from bug 1705211:

1. Navigate to https://alesandroortiz.com/security/firefox/external-protocol/spoof-calc-diff-tab.html
2. Click "Continue to Google.com" button

Observed: Dialog initiated by background page is shown in the currently active tab, even if the tab is on a different origin. Dialog will repeatedly be shown on any of the focused tabs.
Expected: Dialog is only shown in tab containing iframe which opened the dialog, along with appropriate throttling.

Another way to repro is to use Scenario 4's PoC from bug 1705211:

1. Navigate to https://alesandroortiz.com/security/firefox/external-protocol/spoof-iframe-src-calc.html
2. Switch to another tab or open a new tab
3. (Optional:) Continue switching tabs and opening new tabs.

Observed: Same as first PoC in this report.
Expected: Same as first PoC in this report.

VERSION
Firefox Version: 94.0.2 Stable (Build ID 20211119140621), also repros in 96.0a1 Nightly (Build ID 20211202094249)
Operating System: Windows_NT 10.0 19042

CREDIT INFORMATION
Reporter credit: Alesandro Ortiz https://AlesandroOrtiz.com

Comment 1

[Alesandro Ortiz]

Attachment: spoof-iframe-src-calc.html

Comment 2

[Alesandro Ortiz]

Attachment: cross-tab-nightly.mp4

Comment 3

[Alesandro Ortiz]

Attachment: cross-tab-spoof-stable.mp4

Comment 4

[Alesandro Ortiz]

I've attached videos of current Stable and Nightly behavior using the first PoC in this report. Observe how the dialogs appear on any focused tab as long as the initiating background tab is still open. In Stable, this is worse because of the spoof reported in bug 1705211. In Nightly which has fix, impact is less but the persistence and cross-tab presence may be sufficient to trick a user into allowing a malicious site to launch an external protocol.

Comment 5

[Frederik Braun [:freddy]]

Wrong tab. We'll take a look at this one from a bounty perspective, once it's been fixed. Sorry!

Comment 6

[Frederik Braun [:freddy]]

Gah...

Comment 7

[:Gijs (he/him)]

Paul, can you take an initial look as to why these dialogs are appearing in the wrong tab?

Comment 8

[Daniel Veditz [:dveditz]]

Is part of this the timing of a race between opening the new tab and loading the content into a frame? That's less convincing. A better spoof would be if you could launch the external handler 30 seconds later or something (I'll take 5s for a testcase though -- I don't want to wait around 30 seconds to prove it).

Calling it sec-low for now because the timing/spamyness seems to be required and will be putting people on their guard to start with.

Comment 9

[Alesandro Ortiz]

A quick test shows that a malicious page can initiate the dialog at any time, as long as the malicious page is open in a tab. The new tab doesn't need to be opened from the malicious page (i.e. a user can open or switch to another tab on their own, and malicious page can still show dialog at any point.)

PoC A: https://aogarantiza.com/firefox/1744158-a.html -- will show dialog 10 seconds after clicking button

PoC B: https://aogarantiza.com/firefox/1744158-b.html -- will show dialog 20 seconds after page load.

Comment 10

[Emma Zühlcke [:emz]]

Thanks Gijs!

Opening the external protocol in an iframe means we pass null for the embedder element here: https://searchfox.org/mozilla-central/rev/4ca2f73ae9346709d39de2c8fe33874e4203b9e6/toolkit/mozapps/handling/ContentDispatchChooser.jsm#534
Passing null into gBrowser.getTabDialogBox means it will fall back to the selected browser here: https://searchfox.org/mozilla-central/rev/4ca2f73ae9346709d39de2c8fe33874e4203b9e6/browser/base/content/tabbrowser.js#869

I'll work on a fix.

Comment 11

[Emma Zühlcke [:emz]]

Attachment: Bug 1744158, r=Gijs!

Comment 12

[Emma Zühlcke [:emz]]

Attachment: Bug 1744158 - Test, r=Gijs!

Depends on D133392

Comment 13

[Phabricator Automation]

Comment on attachment 9254590 [details]
Bug 1744158 - Test, r=Gijs!

Revision D133393 was moved to bug 1745253. Setting attachment 9254590 [details] to obsolete.

Comment 14

[Emma Zühlcke [:emz]]

Dan, will we change the security rating based on comment 9? I'd like to confirm before landing my patch.

Comment 15

[Frederik Braun [:freddy]]

We'll re-evaluate but this certainly won't pass the bar for sec-high; i.e., You can land this without sec-approval

Comment 16

[Emma Zühlcke [:emz]]

Thanks for confirming! I'll land the fix now and the test later.

Comment 17

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

r=Gijs
https://hg.mozilla.org/integration/autoland/rev/79451984211e7439152084b32ba25611ecbf44ef
https://hg.mozilla.org/mozilla-central/rev/79451984211e

Comment 18

[Alesandro Ortiz]

Verified as fixed in Nightly 2021-12-11 on Windows 10, using PoCs from original report and #c9. Thanks for fixing, :pbz!

Comment 19

[:Gijs (he/him)]

Given 1705211 was uplifted to esr, do we need to uplift this too?

Comment 20

[Ryan VanderMeulen [:RyanVM]]

(In reply to :Gijs (he/him) from comment #19)

Given 1705211 was uplifted to esr, do we need to uplift this too?

Seems reasonable to uplift to Beta/ESR so we get all the relevant fixes shipped in this cycle.

Comment 21

[:Gijs (he/him)]

Comment on attachment 9254589 [details]
Bug 1744158, r=Gijs!

Beta/Release Uplift Approval Request

• User impact if declined: Security issue
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 0
• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Straightforward JS-only change
• String changes made/needed: None

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Security bug related to other sec-moderate that we just uplifted (severity for this one tbc).
• User impact if declined: See above
• Fix Landed on Version: 97 uplift request to 96 pending
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): See above
• String or UUID changes made by this patch: None

Comment 22

[Dianna Smith [:diannaS]]

Comment on attachment 9254589 [details]
Bug 1744158, r=Gijs!

Approved for 96.0b5

Comment 23

[Dianna Smith [:diannaS]]

https://hg.mozilla.org/releases/mozilla-beta/rev/5f11a9c520e9

Comment 24

[Daniel Veditz [:dveditz]]

Thanks to the other bug this popup over the wrong site does now say the correct origin (which might, for all the user knows, be in a frame in that page). Much less spoofy, but still wrong and some users don't read dialogs so we'll also award an incremental bounty for this missing case.

Comment 25

[Alesandro Ortiz]

(From https://bugzilla.mozilla.org/show_bug.cgi?id=1705211#c39 )

Does Mozilla have an automatic disclosure timeline for this type of bug? I'd like to set a date of March 21st, 2022 for public disclosure of this bug and bug 1705211.

Please let me know if the disclosure timeline is acceptable for both bugs.

This allows over 14 weeks for both bug fixes to reach users.

Comment 26

[Daniel Veditz [:dveditz]]

We strongly prefer that disclosure wait until we've shipped patches, and for the most harmful bugs it's good to give people several weeks to patch. This fix is not one of those severe types so any time after we ship 97 (early February?) is fine.

Comment 27

[Alesandro Ortiz]

I agree. The suggested date is about 14 weeks after this bug was marked as fixed (same as Chromium's timeline), which should be sufficient time for users to update.

Using March 21st as disclosure date for now. Thanks for response.

Comment 28

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9254589 [details]
Bug 1744158, r=Gijs!

Approved for 91.5esr.

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/e3675b34e4a5

Comment 30

[Ciprian Georgiu, Desktop QA]

I've reproduced this bug using the STR from comment 0, on Win 10 x64 with Nightly 96.0a1 2021-12-02.

The issue is verified as fixed on the latest builds: Beta 96.0b7, Nightly 97.0a1 and ESR 91.5.

Comment 31

[Frederik Braun [:freddy]]

Attachment: advisory.txt

Comment 32

[Alesandro Ortiz]

Coordinated disclosure date has arrived. Can someone please make this bug public? I've requested the same from Chromium for their related bug.

Comment 33

[Alesandro Ortiz]

Updating needinfo like in bug 1705211