1866100 - (CVE-2024-2609) Firefox external protocol handler prompt is vulnerable to clickjacking

Status: VERIFIED FIXED

(Firefox :: File Handling, defect, P2)

Description

[Shaheen Fazim]

Attachment: demo.mp4

Opening a popup and initiating protocol URI on a hidden window; an attacker can lure the vicitim to clickjack the protocol handler prompt to allow the protocol unknowingly.

Steps to reproduce:

1. Download index.html and popup.html to a folder.
2. Open the index.html and start testing.

Comment 1

[Shaheen Fazim]

Attachment: index.html

Comment 2

[Shaheen Fazim]

Attachment: popup.html

Comment 3

[Daniel Veditz [:dveditz]]

This prompt could be using shared code with the other vulnerable prompts... might be a duplicate in the end. But it's also possible the prompt was simply made following the same style guidelines.

Comment 4

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

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit BugBot documentation.

Comment 5

[Shaheen Fazim]

Hi, friendly ping.

Comment 6

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #3)

This prompt could be using shared code with the other vulnerable prompts... might be a duplicate in the end. But it's also possible the prompt was simply made following the same style guidelines.

The prompt is already using the shared enable delay helper, but the delay helper doesn't detect that the dialog is opened inside a window that is inactive, and so the initial prompt delay expires while the popup window is obscuring the dialog. Then a focus event would re-enable the delay, but that focus event doesn't arrive before the click on the button, but after.

The straightforward fix is to make the enable delay not start "ticking" if the focus target's window is not the active window. This will keep the button disabled if the dialog/window is opened in the background.

The somewhat scary thing here is that this will affect all the consumers of the shared enable delay helper... and I don't know off-hand if there are edgecases where this wouldn't work well.

Comment 7

[:Gijs (he/him)]

Attachment: Bug 1866100 - improve PromptUtils activeness handling, r?pbz

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cc5ae1af4e17
improve PromptUtils activeness handling, r=pbz

Comment 9

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

https://hg.mozilla.org/mozilla-central/rev/cc5ae1af4e17

Comment 10

[Daniel Veditz [:dveditz]]

For just the protocol handler prompt this is not that severe a problem, but since it affects other prompts as well this is a good solid find.

Comment 11

[Shaheen Fazim]

Thank you.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

Do we want this on ESR115 also? Please nominate if so - it grafts cleanly.

Comment 13

[:Gijs (he/him)]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #12)

Do we want this on ESR115 also? Please nominate if so - it grafts cleanly.

I'd want this to bake on release at least for a bit before uplifting as I'm nervous we inadvertently break something here. Focus management is always finnicky/surprising. Ask me again 4 weeks after 124 has been released? :-)

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Can do!

Comment 15

[Daniel Bodea [:danibodea]]

I am attempting to reproduce this issue in Windows10 and MacOS11, but the protocol handler prompt does not appear on the first window when the "Open Popup" button is clicked in an affected build (Release v122.0.1 or v123.0.1 or Nightly v124.0a1 from 2024-01-28). It would appear as if the test page is not working correctly.

@Gijs: Do you know why this happens? Is there some precondition I might be missing out on? Thank you.

Comment 16

[Shaheen Fazim]

(In reply to Daniel Bodea [:danibodea] from comment #15)

I am attempting to reproduce this issue in Windows10 and MacOS11, but the protocol handler prompt does not appear on the first window when the "Open Popup" button is clicked in an affected build (Release v122.0.1 or v123.0.1 or Nightly v124.0a1 from 2024-01-28). It would appear as if the test page is not working correctly.

@Gijs: Do you know why this happens? Is there some precondition I might be missing out on? Thank you.

In the above proof-of-concept, I have used the VSCode protocol handler, so the victim should have installed the VSCode editor as a precondition for this exploit to work. However, there are other protocol handlers that support various applications or OS features.

Comment 17

[:Gijs (he/him)]

(In reply to Daniel Bodea [:danibodea] from comment #15)

I am attempting to reproduce this issue in Windows10 and MacOS11, but the protocol handler prompt does not appear on the first window when the "Open Popup" button is clicked in an affected build (Release v122.0.1 or v123.0.1 or Nightly v124.0a1 from 2024-01-28). It would appear as if the test page is not working correctly.

@Gijs: Do you know why this happens? Is there some precondition I might be missing out on? Thank you.

I think comment 16 answered this but if not please let me know.

Comment 18

[Tyson Smith [:tsmith]]

Attachment: advisory.txt

Comment 19

[Daniel Bodea [:danibodea]]

I can confirm the issue, more exactly, I can confirm that the dialog can be "accidentally" confirmed if the second click falls on the confirmation button, in Nightly v124.0a1 from 2024-02-12. Furthermore, I can confirm the fix. This fix disabled the button in the first moments of the window being focused so it does not allow the user to click it. This behavior helps exclude the "accidental" second click. This fix has been verified in Windows 10 and MacOS 11.

Comment 20

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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 21

[:Gijs (he/him)]

Fixing up flags.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Circling back to this, how are we feeling about an ESR backport?

Comment 23

[:Gijs (he/him)]

Attachment: Bug 1866100 - improve PromptUtils activeness handling, r?pbz

Original Revision: https://phabricator.services.mozilla.com/D200165

Comment 24

[Phabricator Automation]

esr115 Uplift Approval Request

• User impact if declined: sec-moderate
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: see earlier comments in the bug
• Risk associated with taking this patch: Low-ish
• Explanation of risk level: , small change that has baked on release for a bit now
• String changes made/needed: No
• Is Android affected?: no

Comment 25

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/887520530f6e

Comment 26

[Daniel Bodea [:danibodea]]

I have also confirmed the fix in ESR v115.10.0esr on Windows 10 and MacOS 11. The behavior after the fix is described in comment 19.