1876675 - (CVE-2024-2611) Clickjacking to allow permission (bypass of 1863083)

Status: VERIFIED FIXED

(Toolkit :: PopupNotifications and Notification Bars, defect)

Description

[Hafiizh]

Attachment: bypassclickjacking.html

I found a clickjacking vulnerability , bypass on https://bugzilla.mozilla.org/show_bug.cgi?id=1863083. in 1863083 it has been fixed, namely that when the cursor and permissions are in the same coordinates, the cursor cannot be clicked until the cursor is moved. I bypassed it by using pointerlock before the permission prompt appeared for a moment then did pointerlock (cursor disappeared) then it appeared again then clickjacking occurred.

I tested on Firefox version 120.0b4 (64-bit)

steps to reproduce:

1. open bypassclickjacking.html
2. do many clicks on "click here" button with more 200ms delay

Operating System : Windows 10
Firefox version : Firefox developer version 123.0b2 (64-bit)

Comment 1

[Hafiizh]

Attachment: bandicam 2024-01-26 13-03-36-944.mp4

Comment 2

[Hafiizh]

Attachment: bandicam 2024-01-26 13-17-56-562.mp4

Comment 3

[Hafiizh]

Attachment: bandicam 2024-01-26 21-46-22-519.mp4

i also succesfully tested with delay <200ms

Comment 4

[Daniel Veditz [:dveditz]]

(In reply to Hafiizh from comment #0)

I found a clickjacking vulnerability , bypass on https://bugzilla.mozilla.org/show_bug.cgi?id=1863083. in 1863083 it has been fixed, [...]

I tested on Firefox version 120.0b4 (64-bit)

Your older bug was fixed in Firefox 122; a Beta version of 120.0 won't have the fix. Can you confirm that you can still reproduce when you run a Release version of Firefox 122?

Comment 5

[Hafiizh]

sorry, I typed the wrong version, the version I tried was 123.0b5 (64-bit) firefox developer

Comment 6

[Hafiizh]

Attachment: bandicam 2024-02-01 06-34-56-644.mp4

Comment 7

[Emma Zühlcke [:emz]]

I didn't mean to drop the NI here, sorry. I'll take a look.

Comment 8

[Emma Zühlcke [:emz]]

Attachment: 1876675-no-repro.m4v

I can't reproduce this so far. Tested with Nightly 125.0a1 (2024-02-23) (64-bit) on Windows 11. Curious if that's related to reduced motion, which is automatically enabled when using RDP.

Comment 9

[Emma Zühlcke [:emz]]

Hmm.. I can't reproduce with reduced motion disabled either. I've also tested it on ESR 115.8.0.
Gijs if you can spare some time, could you please also try to repro?

Comment 10

[Hafiizh]

Attachment: bandicam 2024-02-24 02-58-25-028.mp4

i tested on 125.0a1 (2024-02-23) (64-bit) nightly version

Comment 11

[Hafiizh]

Attachment: bandicam 2024-02-24 02-54-46-902.mp4

also testd on 124.0b3 (64-bit) firefox developer edition

Comment 12

[:Gijs (he/him)]

I haven't tried to repro, but it somewhat makes sense that if the delay on the popup is 500ms and the repeated clicks happen during the pointer lock time, they don't end up extending the click delay on the button, so after 500ms the popup is accepted. Maybe the timings need changing on a machine performance basis.

Assuming I'm right, this means that changing security.notification_enable_delay would require changes in the testcase in order to keep the pointer locked for a bit longer. Honestly, I'm... not convinced this is a particularly convincing clickjack given all the screen movement and the 500ms delay which isn't being bypassed as such (AFAICT), we're just causing clicks to go elsewhere while the popup is visible the whole time. So sec-moderate seems generous to me.

If we wanted to do something we would probably extend the delay for pointer lock in the same way we did for fullscreen, or close the permission prompt when pointer lock is entered? Paul, is there any reason that wouldn't work?

Comment 13

[Emma Zühlcke [:emz]]

Attachment: Bug 1876675, r=Gijs!

Comment 14

[Emma Zühlcke [:emz]]

Thanks for taking a look Gijs!

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

I'm... not convinced this is a particularly convincing clickjack given all the screen movement and the 500ms delay which isn't being bypassed as such (AFAICT), we're just causing clicks to go elsewhere while the popup is visible the whole time. So sec-moderate seems generous to me.

Agreed. We did introduce the extension of the delay for clicks made during the delay. So that part is being bypassed. But that's a fairly recent addition.

If we wanted to do something we would probably extend the delay for pointer lock in the same way we did for fullscreen, or close the permission prompt when pointer lock is entered? Paul, is there any reason that wouldn't work?

I've attached a patch that does this. Just like for the full screen transition, it needs to account for both pointer lock entered while the panel is open and the panel opening during pointer lock. Still need to work on a test. Probably won't be able to replicate the PoC in CI, given that I can't even reproduce the issue locally.

Edit: we could consider duping Bug 1881846 since it uses the same mechanism.

Comment 15

[Emma Zühlcke [:emz]]

Reporter, could you see if you can still reproduce the issue with this test build:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/E-zReDmmRXmgniXPspQDRA/runs/0/artifacts/public/build/install/sea/target.installer.exe
Note that this behaves like a Nightly installer and will by default overwrite your Nightly installation (if you have one).

If you don't want to use an installer you can also download the archive here: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/E-zReDmmRXmgniXPspQDRA/runs/0/artifacts/public/build/target.zip

Comment 16

[Hafiizh]

Attachment: bandicam 2024-02-28 20-50-09-969.mp4

i confirmed i cannot reproduced the poc using new installer

Comment 17

[Emma Zühlcke [:emz]]

Attachment: Bug 1876675 - Test, r=Gijs!

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3c9e4f296086
r=Gijs

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/3c9e4f296086

Comment 21

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

The patch landed in nightly and beta is affected.
:pbz, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox124 to wontfix.

For more information, please visit BugBot documentation.

Comment 22

[Emma Zühlcke [:emz]]

Attachment: Bug 1876675, r=Gijs!

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

Comment 23

[Phabricator Automation]

Uplift Approval Request

• Code covered by automated testing: yes
• Steps to reproduce for manual QE testing: Please see if you can reproduce the issue using the reporters test page. It may be necessary to change the button coordinates so that it lines up with the mouse position.
• Is Android affected?: no
• User impact if declined: clickjacking issue with permission prompts (see bug POC / video)
• Risk associated with taking this patch: low
• Needs manual QE test: yes
• Fix verified in Nightly: no
• Explanation of risk level: The code change is rather simple, but we risk making permission prompt buttons inoperable for a while when a sites pointer lock requests overlaps with a permission prompt.
• String changes made/needed: none

Comment 24

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/8cf8155621d4

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR115 uplift also when you get a chance.

Comment 26

[Emma Zühlcke [:emz]]

Attachment: Bug 1876675, r=Gijs!

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

Comment 27

[Phabricator Automation]

Uplift Approval Request

• String changes made/needed: none
• Explanation of risk level: The code change is rather simple, but we risk making permission prompt buttons inoperable for a while when a sites pointer lock requests overlaps with a permission prompt.
• Steps to reproduce for manual QE testing: Please see if you can reproduce the issue using the reporters test page. It may be necessary to change the button coordinates so that it lines up with the mouse position.
• Needs manual QE test: yes
• Code covered by automated testing: yes
• User impact if declined: clickjacking issue with permission prompts (see bug POC / video)
• Fix verified in Nightly: no
• Risk associated with taking this patch: low
• Is Android affected?: no

Comment 28

[Pulsebot]

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

Comment 29

[Alexandru Trif, Desktop Test Engineering [:atrif]]

Hello! I managed to reproduce this with Firefox 123.0.1 and Firefox 124.0a1 (2024-01-25) on Windows 10x64 using steps from comment 0, but the reproducing rate is not consistent. I could not reproduce the issue in Ubuntu 23.10 but I could reproduce it on macOS 14 arm with 124.0b6.
I no longer managed to reproduce the issue not even once with different time clicks (above and below 200ms) after trying at least 30 times on each build with Firefox 125.0a1 (2024-03-05), 124.0b7, 115.9.0esr from comment 28 on Windows 10x64. I have also tried some times to reproduce it on macOS 14 arm and Ubuntu 23.10 but without any luck.

However, I have a question: is it expected that the buttons to not be clickable for some time after the Click Here button has been clicked once? Thank you!

Comment 30

[Emma Zühlcke [:emz]]

Thanks! Yes, that's expected. We block the buttons for a few seconds to prevent clickjacking. They should work after waiting (and not clicking) for a few seconds.

Comment 31

[Alexandru Trif, Desktop Test Engineering [:atrif]]

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

Thanks! Yes, that's expected. We block the buttons for a few seconds to prevent clickjacking. They should work after waiting (and not clicking) for a few seconds.

That is correct, they work after some time. Thank you! I think it's safe to close this as verified, as I couldn't reproduce the issue even once while following the steps mentioned in comment 0, despite numerous attempts.

Comment 32

[Tyson Smith [:tsmith]]

Attachment: advisory.txt

Comment 33

[Phabricator Automation]

Comment on attachment 9388071 [details]
Bug 1876675 - Test, r=Gijs!

Revision D202941 was moved to bug 1894203. Setting attachment 9388071 [details] to obsolete.