Clickjacking of permission prompts for camera, microphone, geolocation via full screen
Categories
(Firefox :: Security, defect, P1)
Tracking
()
People
(Reporter: sas.kunz, Assigned: emz)
References
Details
(Keywords: csectype-clickjacking, reporter-external, sec-high, Whiteboard: [adv-main120+][adv-esr115.5+][reporter-external] [client-bounty-form] [verif?])
Attachments
(9 files, 3 obsolete files)
2.46 MB,
video/mp4
|
Details | |
1.10 KB,
text/html
|
Details | |
4.05 MB,
video/mp4
|
Details | |
1.50 KB,
text/html
|
Details | |
5.08 MB,
video/mp4
|
Details | |
2.79 MB,
video/mp4
|
Details | |
1.62 KB,
text/html
|
Details | |
48 bytes,
text/x-phabricator-request
|
diannaS
:
approval-mozilla-beta+
diannaS
:
approval-mozilla-esr115+
tjr
:
sec-approval+
|
Details | Review |
338 bytes,
text/plain
|
Details |
i found a vulnerability where user can fall for clickjacking to allow location permission
I tested on Firefox version 118.0.1 (64-bit)
steps to reproduce:
- Open lock2-1-firefox.html
- fastly move to the "do many clicks here" button.
- Quickly click the "do many clicks here" button 6-7 times without moving the mouse then the location permission will be allowed
references : https://bugzilla.mozilla.org/show_bug.cgi?id=1826116
Comment 4•1 year ago
|
||
Like many of these fullscreen spoofs, this doesn't seem to work on Mac because the fullscreen element is on a different desktop than the the browser chrome. On Mac I'm also clearly seeing the fullscreen toast, which I don't see on the screen recording. Is that an artifact of the recording, or is it really not present on Windows?
I can't quite tell from the movie if the problem is that the permission prompt enable-timer is started while the page is black, or if the prompt shows up already-enabled without the delay. It looks like our black transition is 400ms, while the button delay on the dialog is 500ms. Both values can be adjusted in prefs if that helps determine which it is (e.g. set security.notification_enable_delay
to 5000). That wouldn't be the fix, of course! but if the button is clickable even with such a long timer that's a completely different problem than changing it to not start the timer until the dialog is visible. Or just reject the request if it comes in when the requesting page is not visible or we're in full-screen mode.
When do we change the state internally? Does the transition animation happen outside of being in fullscreen mode, or is it something that happens after we tell the rest of the browser we've entered fullscreen? It really should be inside as far as the rest of the browser is concerned.
Comment 5•1 year ago
|
||
I don't find "keep clicking even though the screen is dark" a very convincing social engineering attack, but if we're allowing clicks even though it's invisible that's wrong. Slightly less bad if it's a timing thing so that it's re-enabled a too-short 100ms after it's visible, but still wrong.
Geolocation is a low-stakes permission, but the prompts share code. I'm more worried the important Camera/Mic and add-on install prompts may have a similar problem.
i have updated the POC:
- Open lock2-1-firefox_new.html
- Quickly click the "do many clicks here" button 3-4 times without moving the mouse then the location permission will be allowed
Reporter | ||
Comment 10•1 year ago
|
||
Comment 11•1 year ago
|
||
(In reply to Hafiizh from comment #8)
i have updated the POC:
- Open lock2-1-firefox_new.html
- Quickly click the "do many clicks here" button 3-4 times without moving the mouse then the location permission will be allowed
Is the 3-4 times just the default timeout on the permission button becoming enabled after bug 1839073? Does extending the timeout for the existing clickjacking protection make this harder to do (ie do you then need to click more often or does it become harder to reproduce?)
Updated•1 year ago
|
Assignee | ||
Comment 12•1 year ago
|
||
Thanks Gijs! I can't test this since I can't reproduce macOS and on Windows 11 using Firefox 119.0. The security delay works on my side, the permission prompt is never granted.
It's possible that full screen behavior is different in a VM though. Confirming whether the timeout still applies by setting the pref to a higher value would be helpful.
Assignee | ||
Comment 13•1 year ago
|
||
I was able to reproduce on a Windows 11 installation (on bare metal) on Nightly from today. When I increase the security delay (via pref) it becomes obvious that the delay isn't actually bypassed. It's likely that the full screen transition is the problem here. The PopupNotification being shown is actually the trigger for exiting fullscreen. Full screen exit is then triggered here. This means the PopupNotification show + security delay and the full screen transition race.
Here are some ideas on how to solve this:
- Start the security delay once the full screen transition has completed. This seems tricky / awkward to do since the PopupNotification code would need to be aware of full screen transitions.
- Block the entire
PopupNotification
show on the full screen transition. Similar to (1). Might fix Bug 1355000 as a side effect. - Skip the full screen transition entirely for cases where we leave full screen because of a permission prompt. We would need to check if that fully addresses the issue, i.e. could there still be issues caused by the full screen enter transition overlapping with the exit transition?
- Don't leave full screen when a permission prompt is showing. This would address this bug, but would reintroduce Bug 1522120 where scam sites can trick the user into accepting permission prompts in full screen where they are less aware of the context of the request.
Here are the prefs I've modified for testing:
full-screen-api.transition-duration.enter
full-screen-api.transition-duration.leave
security.notification_enable_delay
Side-note: the full screen toast message is displayed. However since full screen is rapidly exited and entered it never fully finishes its "slide down" animation if the user spam-clicks very fast.
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 14•1 year ago
|
||
Gijs, do you have a preference for a solution here or different suggestion?
I said that (1) could be a bit arkward, but for a quick fix:
Currently the full screen code observes PopupNotifications. It could also instruct the PopupNotification implementation to restart the security delay timer once it's done with the transition.
Assignee | ||
Updated•1 year ago
|
Comment 15•1 year ago
|
||
(In reply to Paul Zühlcke [:pbz] from comment #14)
Gijs, do you have a preference for a solution here or different suggestion?
I said that (1) could be a bit arkward, but for a quick fix:
Currently the full screen code observes PopupNotifications. It could also instruct the PopupNotification implementation to restart the security delay timer once it's done with the transition.
I think I'd probably pick 2+3 (both) as being longer-term the best way of dealing with this, but that's without having thought much about how hard it would be to do that - how difficult are those options?
Assignee | ||
Comment 16•1 year ago
|
||
For (2):
In order to block the PopupNotification
panel showing on the full screen transition we would have to do the following in PopupNotifications._showPanel:
- Check if currently in DOM full screen or in the transition into or out of full screen. If not, show panel
- If in DOM full screen trigger a full screen exit and wait for the full screen transition to complete, show the panel
- If already transitioning out of full screen wait for the transition to complete and show the panel
The problem is that _showPanel
is a sync method and it has a lot of consumers. We need to check how hard it would be to make it async. This doesn't seem like a quick fix.
For (3):
I was just in a call with Abhishek and we confirmed that disabling the transition fixes the issue. I'm not sure if that works on all machines though, e.g. what about slow machines where updating the layout for full screen exit just takes longer? Just disabling the transition animation won't magically make this fast. We would still have a race condition of the full screen exit and the security delay timer.
Side note:
For (4) we have a pref permissions.fullscreen.allowed
. Setting that to true
means we no longer exit full screen which fixes the issue, but I don't think we want to introduce the other bug again.
Assignee | ||
Comment 17•1 year ago
|
||
There is another option (5):
If in DOM full screen, suppress popup notifications and auto deny permission requests. This could lead to website breakage though since e.g. chrome is allowing the permission requests in full screen. Chrome stays in full screen but shows the chrome UI when the permission prompt appears. It's a bit janky but it works.
Comment 18•1 year ago
|
||
(In reply to Paul Zühlcke [:pbz] from comment #17)
Chrome stays in full screen but shows the chrome UI when the permission prompt appears. It's a bit janky but it works.
How hard would it be to do that instead?
Comment 19•1 year ago
|
||
Assignee | ||
Comment 20•1 year ago
|
||
(In reply to :Gijs (he/him) from comment #18)
(In reply to Paul Zühlcke [:pbz] from comment #17)
Chrome stays in full screen but shows the chrome UI when the permission prompt appears. It's a bit janky but it works.
How hard would it be to do that instead?
I haven't worked with our full screen code yet so I'm not sure how complicated it would be to show the chrome UI in DOM full screen. I'll look into it.
Taking over this bug from Abhishek since he doesn't have a Windows machine to test on. Thanks for the patch draft!
Assignee | ||
Comment 21•1 year ago
|
||
Assignee | ||
Comment 22•1 year ago
|
||
Depends on D192370
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Comment 23•1 year ago
|
||
Met with Gijs today, we opted for the following to fixes:
- Short term: (1) Extend the security delay when exiting DOM full screen because of a permission prompt. I've attached patches for that. Should be fairly easy to uplift.
- Long term: (2) Extend the
PopupNotifications
code to detect that the browser is in exiting full screen and delay showing the panel until after the full screen exit transition has finished.
We can add a promise the full screen code provides thatPopupNotifications
show canawait
. If there is no full screen transition the promise can simply benull
causing the panel to be shown after 1 tick.
Updated•1 year ago
|
Updated•1 year ago
|
Assignee | ||
Comment 24•1 year ago
|
||
Comment on attachment 9361265 [details]
Bug 1857430, r=Gijs!
Security Approval Request
- How easily could an exploit be constructed based on the patch?: Fairly easy. While not directly showing a PoC, the patch makes it obvious that there is an issue with full screen exit paired with the security delay.
- 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?: Minimal change of code that isn't updated often. Will most likely apply cleanly.
- How likely is this patch to cause regressions; how much testing does it need?: Low likelihood of regressions. Small code change that has automated test coverage.
This quick fix increases the security delay when we leave full screen due to a permission prompt showing up. It may bad UX where a user has to wait ~ 2 seconds before they can interact with the prompt. - Is Android affected?: Unknown
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 25•1 year ago
|
||
Requested sec-approval for the "quick fix" of extending the security delay. The long-term fix should be made here: https://bugzilla.mozilla.org/show_bug.cgi?id=1355000#c10
Updated•1 year ago
|
Comment 26•1 year ago
|
||
Comment on attachment 9361265 [details]
Bug 1857430, r=Gijs!
Approved to land and request uplift
Comment 27•1 year ago
|
||
Comment on attachment 9361266 [details]
Bug 1857430 - Test. r=Gijs!
Test approved to land after Jan 9th
Updated•1 year ago
|
Assignee | ||
Comment 28•1 year ago
|
||
Original Revision: https://phabricator.services.mozilla.com/D192370
Updated•1 year ago
|
Updated•1 year ago
|
Comment 29•1 year ago
|
||
![]() |
||
Comment 30•1 year ago
|
||
Assignee | ||
Comment 31•1 year ago
|
||
Comment on attachment 9361265 [details]
Bug 1857430, r=Gijs!
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration:
- User impact if declined: Clickjacking risk where attackers can trick users into allowing access to sensitive permissions for camera, microphone, location etc.
- Fix Landed on Version: 121
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): The code change is small and only applies to the specific affected use case. We only extend the security delay when exiting full screen because of a permission prompt showing. I don't expect this to be very common on the web.
Beta/Release Uplift Approval Request
- User impact if declined: See ESR request
- 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: https://bugzilla.mozilla.org/show_bug.cgi?id=1857430#c0
Without the patch the prompt will be accepted almost instantly after full screen exit. with the patch there should be a longer ~2 second delay so the user has a chance to react. - List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): See ESR uplift request
- String changes made/needed:
- Is Android affected?: Unknown
Assignee | ||
Updated•1 year ago
|
Comment 32•1 year ago
|
||
Comment on attachment 9361265 [details]
Bug 1857430, r=Gijs!
Approved for 120.0b9
Approved for 115.5esr
Comment 33•1 year ago
|
||
uplift |
Updated•1 year ago
|
Comment 34•1 year ago
|
||
uplift |
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 35•1 year ago
•
|
||
I have reproduced this issue on Win 11 x64 using STR from comment 0, on an affected Nightly build (2023-10-06).
The issue is verified as fixed on the latest builds, 121.0a1 Nightly, 120 RC and 115.5 esr.
Reporter | ||
Comment 36•1 year ago
|
||
hello thank you, how much bounty do I receive?
Comment 37•1 year ago
|
||
Sorry, looks like we missed the attachment, I have added it.
Updated•1 year ago
|
Comment 38•1 year ago
|
||
Updated•1 year ago
|
Comment 39•1 year ago
|
||
2 months ago, tjr placed a reminder on the bug using the whiteboard tag [reminder-test 2024-01-09]
.
pbz, please refer to the original comment to better understand the reason for the reminder.
Comment 40•1 year ago
|
||
Comment on attachment 9361266 [details]
Bug 1857430 - Test. r=Gijs!
Revision D192371 was moved to bug 1873960. Setting attachment 9361266 [details] to obsolete.
Assignee | ||
Updated•1 year ago
|
Comment 41•10 months ago
|
||
Bulk-unhiding security bugs fixed in Firefox 119-121 (Fall 2023). Use "moo-doctrine-subsidy" to filter
Updated•9 months ago
|
Updated•8 months ago
|
Description
•