Closed Bug 1857430 (CVE-2023-6206) Opened 1 year ago Closed 1 year ago

Clickjacking of permission prompts for camera, microphone, geolocation via full screen

Categories

(Firefox :: Security, defect, P1)

defect

Tracking

()

VERIFIED FIXED
121 Branch
Tracking Status
firefox-esr115 120+ verified
firefox119 --- wontfix
firefox120 + verified
firefox121 + verified

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)

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:

  1. Open lock2-1-firefox.html
  2. fastly move to the "do many clicks here" button.
  3. 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

Flags: sec-bounty?
Attached file lock2-1-firefox.html

i also tested on Firefox developer Edition 119.0b6 (64-bit)

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.

Flags: needinfo?(echen)

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:

  1. Open lock2-1-firefox_new.html
  2. Quickly click the "do many clicks here" button 3-4 times without moving the mouse then the location permission will be allowed
Attached video camerapermission.mp4
Attached file cameraaccess.html

(In reply to Hafiizh from comment #8)

i have updated the POC:

  1. Open lock2-1-firefox_new.html
  2. 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?)

Flags: needinfo?(sas.kunz)
Flags: needinfo?(pbz)
See Also: → CVE-2023-4047

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.

Flags: needinfo?(pbz)
Assignee: nobody → amadan

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:

  1. 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.
  2. Block the entire PopupNotification show on the full screen transition. Similar to (1). Might fix Bug 1355000 as a side effect.
  3. 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?
  4. 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.

Severity: -- → S2
Priority: -- → P1

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.

Flags: needinfo?(gijskruitbosch+bugs)
Summary: Security bug Clickjacking to allowed location permission → Clickjacking of permission prompts for camera, microphone, geolocation via full screen

(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?

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(pbz)

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.

Flags: needinfo?(pbz)

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.

(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?

(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: amadan → pbz
Status: NEW → ASSIGNED
Attached file Bug 1857430, r=Gijs!
Attached file Bug 1857430 - Test. r=Gijs! (obsolete) —

Depends on D192370

Attachment #9361265 - Attachment description: WIP: Bug 1857430, r=Gijs! → Bug 1857430, r=Gijs!
Attachment #9361266 - Attachment description: WIP: Bug 1857430 - Test. r=Gijs! → Bug 1857430 - Test. r=Gijs!

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 that PopupNotifications show can await. If there is no full screen transition the promise can simply be null causing the panel to be shown after 1 tick.
Attachment #9360913 - Attachment is obsolete: true
See Also: → 1355000
See Also: → CVE-2024-1550

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
Attachment #9361265 - Flags: sec-approval?
Attachment #9361266 - Flags: sec-approval?

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

Comment on attachment 9361265 [details]
Bug 1857430, r=Gijs!

Approved to land and request uplift

Attachment #9361265 - Flags: sec-approval? → sec-approval+

Comment on attachment 9361266 [details]
Bug 1857430 - Test. r=Gijs!

Test approved to land after Jan 9th

Attachment #9361266 - Flags: sec-approval?
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][reminder-test 2024-01-09]
Attached file Bug 1857430, r=Gijs! (obsolete) —
Attachment #9362305 - Flags: approval-mozilla-beta?
Attachment #9362305 - Attachment is obsolete: true
Attachment #9362305 - Flags: approval-mozilla-beta?
Group: firefox-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 121 Branch

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
Attachment #9361265 - Flags: approval-mozilla-esr115?
Attachment #9361265 - Flags: approval-mozilla-beta?
Flags: qe-verify+

Comment on attachment 9361265 [details]
Bug 1857430, r=Gijs!

Approved for 120.0b9
Approved for 115.5esr

Attachment #9361265 - Flags: approval-mozilla-esr115?
Attachment #9361265 - Flags: approval-mozilla-esr115+
Attachment #9361265 - Flags: approval-mozilla-beta?
Attachment #9361265 - Flags: approval-mozilla-beta+
Flags: needinfo?(echen)
Flags: needinfo?(sas.kunz)
QA Whiteboard: [qa-triaged]
Flags: sec-bounty? → sec-bounty+

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.

Status: RESOLVED → VERIFIED
Flags: qe-verify+

hello thank you, how much bounty do I receive?

Sorry, looks like we missed the attachment, I have added it.

Whiteboard: [reporter-external] [client-bounty-form] [verif?][reminder-test 2024-01-09] → [adv-main120+][adv-esr115.5+][reporter-external] [client-bounty-form] [verif?][reminder-test 2024-01-09]
Alias: CVE-2023-6206
See Also: → 1865465
See Also: → 1865914

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.

Flags: needinfo?(pbz)
Whiteboard: [adv-main120+][adv-esr115.5+][reporter-external] [client-bounty-form] [verif?][reminder-test 2024-01-09] → [adv-main120+][adv-esr115.5+][reporter-external] [client-bounty-form] [verif?]
Blocks: 1873960

Comment on attachment 9361266 [details]
Bug 1857430 - Test. r=Gijs!

Revision D192371 was moved to bug 1873960. Setting attachment 9361266 [details] to obsolete.

Attachment #9361266 - Attachment is obsolete: true
Flags: needinfo?(pbz)

Bulk-unhiding security bugs fixed in Firefox 119-121 (Fall 2023). Use "moo-doctrine-subsidy" to filter

Group: core-security-release
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: