1839073 - (CVE-2023-4047) Bypass site permission clickjacking protections on Desktop by opening a new tab with window.open() and closing it after the permission timeout has expired

Status: VERIFIED FIXED

(Toolkit :: PopupNotifications and Notification Bars, defect, P1)

Description

[haxatron1]

By opening a new window maintaining it for 500ms and closing it, it bypasses clickjacking protections.

1. Go to https://haxatron1-bugs.glitch.me/clickjack.html and spam click on button

Comment 1

[haxatron1]

Attachment: Untitled_ Jun 18, 2023 11_22 PM.webm

video

Comment 2

[haxatron1]

Attachment: clickjack.html

Comment 3

[haxatron1]

Attachment: Untitled_ Jun 18, 2023 11_30 PM.webm

Comment 4

[haxatron1]

I have a made a site for you to test the control setup so you can see the difference with opening a new window and without open a new window (bypass)

This URL is the site without opening a new window https://haxatron1-bugs.glitch.me/clickjack2.html.

Comment 5

[haxatron1]

For an even easier reproduction, go to about:config and set the activation delay parameter to 5000 =>

security.notification_enable_delay

Then reproduce the same on https://haxatron1-bugs.glitch.me/clickjack3.html, in this test case it is really obvious that the clickjacking protections are bypassed.

Comment 6

[haxatron1]

(In reply to haxatron1 from comment #5)

For an even easier reproduction, go to about:config and set the activation delay parameter to 5000 =>

security.notification_enable_delay

Then reproduce the same on https://haxatron1-bugs.glitch.me/clickjack3.html, in this test case it is really obvious that the clickjacking protections are bypassed.

browser has to be restarted first before the configuration can be applied.

Comment 7

[:Gijs (he/him)]

Paul, can you take a look? I feel like bug 1826116 should have fixed this.

Comment 8

[Emma Zühlcke [:emz]]

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

Paul, can you take a look? I feel like bug 1826116 should have fixed this.

You might be right. I can't reproduce this on Firefox release or Nightly. I've set my security delay to 5000 and tested with the page linked in comment 0.

Reporter, which version of Firefox did you use to test this? Could you confirm that it still works on 114.0.1 or higher?

Comment 9

[haxatron1]

Reproduced on Windows FF 114.0.1 (64-bit)

Please use https://haxatron1-bugs.glitch.me/clickjack3.html for the 5000 ms delay, comment 0 is configured for the 500 ms delay

Comment 10

[haxatron1]

let me know if you are still not able to reproduce

Comment 11

[haxatron1]

If still not able to reproduce can also try, https://haxatron1-bugs.glitch.me/clickjack4.html which increases from 10ms to 50ms delay for the window.open() opens the new page. The important thing is that the geolocation pemission prompt must be registered first before the call to window.open()

Comment 12

[haxatron1]

The POC positioning also might be a bit off with the bookmarks bar. On my Firefox (both nightly and 114 build), I changed bookmarks bar to show only on new tab.

Comment 13

[:Gijs (he/him)]

(In reply to Paul Zühlcke [:pbz] from comment #8)

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

Paul, can you take a look? I feel like bug 1826116 should have fixed this.

For the avoidance of doubt, I can repro on 116. I just don't understand why/how, as I thought the other bug was supposed to have fixed this.

Is it possible that we either don't cancel the timeout when the popup is hidden, or don't restart the timer when the popup is reshown, or something?

Comment 14

[haxatron1]

Attachment: clickjack-long-delay.html

Comment 15

[haxatron1]

To prevent me from accidentally modifying my own PoC, I have deleted the test cases from my my hosted website and uploaded the 5000ms delay test case onto bugzilla so that you can test on bugzilla as well. I have also moved all test cases under https://haxatron1-bugs.glitch.me/b1839073/

Comment 16

[Emma Zühlcke [:emz]]

Sorry, I had misunderstood the PoC, I can reproduce now. This is a regression of Bug 1826116 where we changed when timeShown is set. I verified this by testing with that patch reverted.
I still need to look into it more but I suspect it's because we set timeShown before the hidePanel promise resolves.

Comment 18

[Emma Zühlcke [:emz]]

I think the problem is that we don't override timeShown when we call _showPanel for when we re-show it after a tab switch. See https://searchfox.org/mozilla-central/rev/3424c000a7ff304b2d1efb8561a924232f7f12fc/toolkit/modules/PopupNotifications.sys.mjs#1262

I'll submit a patch.

Comment 19

[Emma Zühlcke [:emz]]

Attachment: Bug 1839073, r=Gijs!

Comment 20

[Emma Zühlcke [:emz]]

Attachment: Bug 1839073 - Test. r=Gijs!

Depends on D181779

Comment 21

[Emma Zühlcke [:emz]]

We have a fix, but I'm holding off from landing since this is still pending a sec rating.

Comment 22

[haxatron1]

(In reply to Paul Zühlcke [:pbz] from comment #21)

We have a fix, but I'm holding off from landing since this is still pending a sec rating.

I think it should be the same as https://bugzilla.mozilla.org/show_bug.cgi?id=1826116?

Comment 23

[Emma Zühlcke [:emz]]

Comment on attachment 9340510 [details]
Bug 1839073, r=Gijs!

Security Approval Request

• How easily could an exploit be constructed based on the patch?: The patch makes it obvious that there is a bug with our security delay in PopupNotifications. It does however not show the exact conditions that are needed in order for this to be exploited.
  Similar to Bug 1826116.
• 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?: I don't expect any merge conflicts since for Bug 1826116 we already backported. This patch is a one-line change on top of that.
• How likely is this patch to cause regressions; how much testing does it need?: It's a very small change and has been verified locally.
  However updating the security delay comes with the risk of breaking PopupNotification buttons. There is also the risk that we further regress and break the security delay more.
  The test for Bug 1826116 and the one included in the other patch for this bug increase our test coverage of the security delay mechanism.
• Is Android affected?: No

Comment 25

[Tom Ritter [:tjr]]

Comment on attachment 9340511 [details]
Bug 1839073 - Test. r=Gijs!

Clearing flag for test

Comment 26

[Tom Ritter [:tjr]]

Comment on attachment 9340510 [details]
Bug 1839073, r=Gijs!

Approved to uplift and land

Comment 27

[haxatron1]

(In reply to haxatron1 from comment #22)

(In reply to Paul Zühlcke [:pbz] from comment #21)

We have a fix, but I'm holding off from landing since this is still pending a sec rating.

I think it should be the same as https://bugzilla.mozilla.org/show_bug.cgi?id=1826116?

For sec-severity, a attack scenario would be asking the user to open the new about:blank window to start a game, and when enough clicks occur in the game, the window closes and the victim accidentally clicks on the accept button of the prompt.

Comment 28

[Emma Zühlcke [:emz]]

Attachment: Bug 1839073, r=Gijs!

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

Comment 29

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/mozilla-central/rev/75b8d8d5ea21
r=emilio

Comment 30

[Emma Zühlcke [:emz]]

Comment on attachment 9340510 [details]
Bug 1839073, r=Gijs!

Beta/Release Uplift Approval Request

• User impact if declined: Clickjacking sec-bug. Users may be tricked into accepting permission prompts, e.g. geolocation, camera, microphone, ...
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 0
  It should not be possible to interact with the prompt directly after it becomes visible. Users should only be able to interact with the Block/Allow buttons after the security delay (500 ms).
  To better test this you can also increase the security delay via pref, see https://bugzilla.mozilla.org/show_bug.cgi?id=1839073#c5
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): It's a very small change and has been verified locally and has test coverage (test landing separately).
  However updating the security delay comes with the risk of breaking PopupNotification buttons. There is also the risk that we further regress and break the security delay more.
• String changes made/needed:
• Is Android affected?: No

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration:
• User impact if declined: See beta uplift request
• Fix Landed on Version:
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): See beta uplift request

Comment 31

[Emma Zühlcke [:emz]]

It would be nice to get QA verification prior to the uplifts. I'm mentioning this because in the past we had uplifts done before the verification.

Comment 32

[Bogdan Maris, Desktop Test Engineering]

I tried to reproduce using 116.0b3 and 114.0.1 on Windows 10 and Windows 11 but I only managed to reproduce twice from I don't know how many tries I had so I don't think I can reliably verify this as being fixed.
These are the steps I used:

1. Changed the security.notification_enable_delay pref to 5000
2. Loaded https://haxatron1-bugs.glitch.me/clickjack3.html or the clickjack-long-delay.html file attached in the bug
3. Clicked the button (and kept clicking in the same spot where the Allow button from the notification is)
4. Closed the new blank opened window (using keyboard shortcut)

Result: Clicking on the Allow did nothing for a few seconds (the delay) only after the delay was over the click was registered on Allow and the coordinates were displayed.

I don't know if I missed something but if not, could you please verify that this is fixed for you using the latest Nightly 117.0a1 build? https://archive.mozilla.org/pub/firefox/nightly/2023/07/2023-07-10-09-40-14-mozilla-central/firefox-117.0a1.en-US.win64.zip

Comment 33

[haxatron1]

For Step 4, you have to wait the full 5000ms (when using the security pref) instead of closing the keyboard shortcut.

I can verify this as fixed on Build 17.0a1 (2023-07-10) (64-bit

Comment 34

[haxatron1]

build 117.0a1 (2023-07-10) (64-bit)*

Comment 35

[Bogdan Maris, Desktop Test Engineering]

(In reply to haxatron1 from comment #33)

For Step 4, you have to wait the full 5000ms (when using the security pref) instead of closing the keyboard shortcut.

I can verify this as fixed on Build 17.0a1 (2023-07-10) (64-bit

I get it now, I was able to reproduce it myself on the old build! \o/
Thanks for verifying on above build, I was also able to verify that this is fixed using the latest Nightly from today 2023-07-11) on both Windows 10 64bit and Windows 11.

Comment 36

[Dianna Smith [:diannaS]]

Comment on attachment 9340510 [details]
Bug 1839073, r=Gijs!

Approved for 116.0b4

Comment 37

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/b5dd2d4077b7

Comment 39

[Daniel Veditz [:dveditz]]

The test examples use the less scary geolocation prompt, but this applies to all similar prompts and the sec-high is given assuming scarier permissions like camera/mic ones.

Comment 40

[Bogdan Maris, Desktop Test Engineering]

Also verified as fixed using latest Beta build 116.0b4 across platforms (Windows 10, macOS 13.2 and Ubuntu 22.04).

Comment 41

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9340510 [details]
Bug 1839073, r=Gijs!

Approved for 115.1esr.

Comment 42

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/ea939ed893bc

Comment 43

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9340510 [details]
Bug 1839073, r=Gijs!

And 102.14esr.

Comment 44

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr102/rev/acd5ece8baec

Comment 45

[Bogdan Maris, Desktop Test Engineering]

Verified on both esr102 and esr115 builds across platforms (Windows 10, macOS 13.2 and Ubuntu 22.04) from treeherder that contain the fix.

Comment 46

[Phabricator Automation]

Comment on attachment 9340511 [details]
Bug 1839073 - Test. r=Gijs!

Revision D181780 was moved to bug 1844776. Setting attachment 9340511 [details] to obsolete.

Comment 47

[Jesse Schwartzentruber (:truber)]

Attachment: advisory.txt

Comment 48

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

2 months ago, tjr placed a reminder on the bug using the whiteboard tag [reminder-test 2023-09-12] .

pbz, please refer to the original comment to better understand the reason for the reminder.

Comment 49

[Emma Zühlcke [:emz]]

Queued the test for landing.