Closed Bug 1826116 (CVE-2023-32207) Opened 1 year ago Closed 11 months ago

Clickjacking to allowed location permission (bypassing button-enable delay)

Categories

(Firefox :: Site Permissions, defect, P1)

defect

Tracking

()

VERIFIED FIXED
114 Branch
Tracking Status
firefox-esr102 113+ verified
firefox112 --- wontfix
firefox113 + verified
firefox114 + verified

People

(Reporter: sas.kunz, Assigned: pbz)

References

Details

(Keywords: csectype-priv-escalation, csectype-spoof, sec-high, Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main113+][adv-ESR102.11+])

Attachments

(16 files)

i found a vulnerability where user can fall for clickjacking to allow location permission

I tested on Firefox version 111.0.1 (64-bit)

steps to reproduce:

  1. open https://pipabajabakrie.com/upload/geofullscreen6.html
  2. Click the "try it" button. then it will appear in fullscreen mode
  3. Quickly click the "try it" button 3 times without moving the mouse then the location permission will be allowed

I am attaching 2 videos. one video on firefox and another on chrome where in chrome the mouse click doesn't work in notification permission with same steps to reproduces

Flags: sec-bounty?
Attached file clickjacking.html
Component: Security → Site Permissions

Is the security dialog activation delay on permission prompts gone? That was supposed to prevent exactly this kind of attack (bug 162020)

Flags: needinfo?(gijskruitbosch+bugs)

I'm not overly concerned about location permission, and the particular testcase here doesn't work at all for any of us (spacing is way off, but fixable), but if it's the fault of the permission code it would apply to more serious permissions like camera/mic access, extension installs, etc.

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

Is the security dialog activation delay on permission prompts gone? That was supposed to prevent exactly this kind of attack (bug 162020)

I don't know. 302 Paul who knows this code better than I do. https://searchfox.org/mozilla-central/rev/da8f8e5fd1cc02a9be7ce26b7d3f91deb18159bf/toolkit/modules/PopupNotifications.sys.mjs#1872-1879 certainly still looks like it's there.

Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(pbz)
Attached file camera.html

poc for camera permission

The test cases presented so far don't seem very reliable. I can't get them to work on my machine at all (both Ubuntu and Windows10). May require specific positioning for different resolutions or OS. Also the attacker would need to get the user to spam-click the button.

Testing the clickjacking delay manually on https://permission.site it works fine and logs:

PopupNotifications._onButtonEvent: Button click happened before the security delay: 276.8355469999806ms 

The click jack delay is rather short, so perhaps we're running over that.
Reporter, could you set the pref security.notification_enable_delay to a higher number, like 5000 (5 seconds) to see if the issue still reproduces? I want to find out if this is bypassing our delay mechanism. Thanks!

I'm also wondering if it has to do with the way we remove PopupNotifications when entering fullscreen or how we leave fullscreen when a PopupNotification is shown.

Flags: needinfo?(pbz) → needinfo?(sas.kunz)
Attached video setto5000.mp4
Flags: needinfo?(sas.kunz)

Sorry I forgot to mention, you may need to restart Firefox after setting the pref in order for this to apply. Could you please check again? Much appreciated!

Flags: needinfo?(sas.kunz)
Attached video setto5000restart.mp4
Flags: needinfo?(sas.kunz)
Attached image mouse_setting.jpg
Attached image specificationlaptop.jpg

i use v-track gaming mouse f4

Attached video camerapermission.mp4

Thank you, that's very helpful. So it looks like this bypasses the delay somehow.

Paul, are you still investigating this further based on the latest update from the reporter?

Flags: needinfo?(pbz)

i tested on other notebook , it is affected too . i tested on HP elitebook 830 G6 with same configuration. (WIndows 10 Pro 64 Bit)

I find it quite concerning if a rapid, well-positioned click can bypass our "security delay". Let's start with sec-moderate, but one could argue this is sec-high - especially if it uncovers that the delay is bypassable in our various other dialogs.

Keywords: sec-moderate
Assignee: nobody → pbz
Severity: -- → S2
Status: NEW → ASSIGNED
Flags: needinfo?(pbz)
Priority: -- → P1

I can reproduce on a Windows 10 VM. The issue is here: https://searchfox.org/mozilla-central/rev/a4fb94aab371d8650d194558c77879f5b8842380/toolkit/modules/PopupNotifications.sys.mjs#1871
where notification.timeShown is null which leads to timeSinceShown < buttonDelay to always evaluate to false. Still investigating the root cause.

For the open call of the affected popup notification we run into this case: https://searchfox.org/mozilla-central/rev/a4fb94aab371d8650d194558c77879f5b8842380/toolkit/modules/PopupNotifications.sys.mjs#1247,1266

We assume that the panel is already open and thus skip the remaining open steps. Which means we never end up setting n.timeShown further down in that method: https://searchfox.org/mozilla-central/rev/a4fb94aab371d8650d194558c77879f5b8842380/toolkit/modules/PopupNotifications.sys.mjs#1287
I assume there is a race condition, since the PoC code causes _showPanel to be called two times (while doing the fullscreen transition).

Generally I'm wondering if we could tie the timeShown timestamp closer to the actual show call. That would make the code a lot more resilient against these types of attacks.

Attached file Bug 1826116 r=Gijs!
Attachment #9329740 - Attachment description: WIP: Bug 1826116 - Ensure notification.timeShown is set on PopupNotification button command. → WIP: Bug 1826116 - Ensure notification.timeShown is set before before PopupNotification button events.
Attachment #9329740 - Attachment description: WIP: Bug 1826116 - Ensure notification.timeShown is set before before PopupNotification button events. → WIP: Bug 1826116 - Ensure notification.timeShown is set before PopupNotification button events.
Attachment #9329740 - Attachment description: WIP: Bug 1826116 - Ensure notification.timeShown is set before PopupNotification button events. → Bug 1826116 - Ensure notification.timeShown is set before PopupNotification button events. r=Gijs!

I don't understand why it is set to sec-moderate, I have tried to bypass the camera permission and it worked and it also affected the other permissions

Depends on D176174

Attachment #9329740 - Attachment description: Bug 1826116 - Ensure notification.timeShown is set before PopupNotification button events. r=Gijs! → Bug 1826116 r=Gijs!
Attachment #9330606 - Flags: sec-approval?

Comment on attachment 9329740 [details]
Bug 1826116 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.
  • 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 supported branches (including ESR)
  • 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?: Should be fairly easy to create backports if the patch doesn't apply as-is already.
  • How likely is this patch to cause regressions; how much testing does it need?: There is the low risk of further breaking our security delay checks, because we updated our timestamp logic (timeShown). We have an automated test that covers the patch. The test has been verified locally.

Here is a try run (without the new test): https://treeherder.mozilla.org/jobs?repo=try&resultStatus=testfailed%2Cbusted%2Cexception&classifiedState=unclassified&revision=e6775b4db0be61cbaed658af85fc2f123aa4c50c&selectedTaskRun=aN3D-CFASBeIrCPwN4G3Xw.0

  • Is Android affected?: No
Attachment #9329740 - Flags: sec-approval?

[Tracking Requested - why for this release]: sec-medium, potential sec-high, may be worth getting into late Fx113 or RC. sec-approval pending above.

(In reply to Hafiizh from comment #23)

I don't understand why it is set to sec-moderate, I have tried to bypass the camera permission and it worked and it also affected the other permissions

The camera/mic permission clearly raises the stakes--after all, that was the primary Flash POC that launched the very term "clickjacking".

But mainly this was rated moderate because the POCs didn't work against most of us which raises doubts about how reliable it could be. Also some thought the multiple clicks required were clunky and would be hard to elicit, greatly reducing the potential affected population. Personally I'm still concerned about the reliability of the click targeting on different systems (can you reliably detect the scaling factor in use?), but I have no trouble imagining a scenario where a victim wants to go into fullscreen (show a movie or game? there's one free click), and then interactive content (ok, not a movie) could come up with any number of reasons the user would want to click or double-click in the right spot.

sec-high is a reasonable rating.

You showed us a bunch of detail about your system and I may have missed it, but I didn't see the bits that I suspect are most relevant to the click targeting: your screen resolution and the "scaling factor" in your OS settings. I'm sure you can detect the screen resolution (especially once you know you're in fullscreen) but I'm less sure about scaling.

Comment on attachment 9329740 [details]
Bug 1826116 r=Gijs!

sec-approval a=dveditz for right now so we can get it into the 113 release
beta-uplift and ESR-102 uplift approved, a=dveditz

I don't believe we need a release branch approval as long as it lands before the RC branch is tagged.

Attachment #9329740 - Flags: sec-approval?
Attachment #9329740 - Flags: sec-approval+
Attachment #9329740 - Flags: approval-mozilla-esr102+
Attachment #9329740 - Flags: approval-mozilla-beta+

Comment on attachment 9330606 [details]
Bug 1826116 - Test r=Gijs!

This test looks un-revealing enough to land with the patch

Attachment #9330606 - Flags: sec-approval?
Attachment #9330606 - Flags: sec-approval+
Attachment #9330606 - Flags: approval-mozilla-esr102+
Attachment #9330606 - Flags: approval-mozilla-beta+

I don't believe we need a release branch approval as long as it lands before the RC branch is tagged.

Ideally land ASAP so we can get a bit of nightly testing over the weekend, but that could be problematic since it's a 4-day weekend for a lot of our European employees.

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

I don't believe we need a release branch approval as long as it lands before the RC branch is tagged.

Ideally land ASAP so we can get a bit of nightly testing over the weekend, but that could be problematic since it's a 4-day weekend for a lot of our European employees.

Thanks for the quick turnaround!
I had queued it on autoland shortly after approval: https://hg.mozilla.org/integration/autoland/rev/edf238a3c42594f877ab3094aac3cb024fe7d653
Hasn’t landed yet.

Landed:
https://hg.mozilla.org/integration/autoland/rev/edf238a3c42594f877ab3094aac3cb024fe7d653
https://hg.mozilla.org/integration/autoland/rev/4b3e3f8ff22ec6c70d792bedf72d0a5b583895d3

Backed out for causing bc failures in browser_popupNotification_security_delay.js:
https://hg.mozilla.org/integration/autoland/rev/b102da10b16823efed532ce69484071b3b98edae

Push with failure
Failure log

[task 2023-04-27T21:22:44.253Z] 21:22:44     INFO - TEST-PASS | browser/base/content/test/popupNotifications/browser_popupNotification_security_delay.js | at least one notification displayed - 
[task 2023-04-27T21:22:44.253Z] 21:22:44     INFO - Triggering main command for notification foo-notification
[task 2023-04-27T21:22:44.253Z] 21:22:44     INFO - Buffered messages finished
[task 2023-04-27T21:22:44.253Z] 21:22:44     INFO - TEST-UNEXPECTED-FAIL | browser/base/content/test/popupNotifications/browser_popupNotification_security_delay.js | PopupNotification should still be open. - 
[task 2023-04-27T21:22:44.253Z] 21:22:44     INFO - Stack trace:
[task 2023-04-27T21:22:44.253Z] 21:22:44     INFO - chrome://mochikit/content/browser-test.js:test_ok:1584
[task 2023-04-27T21:22:44.253Z] 21:22:44     INFO - chrome://mochitests/content/browser/browser/base/content/test/popupNotifications/browser_popupNotification_security_delay.js:test_timeShownMultipleNotifications:129
Flags: needinfo?(pbz)

I re-landed just D176174 given the time pressures here.

Keywords: leave-open

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

I re-landed just D176174 given the time pressures here.

Thank you! The test passes on its own (tested on Ubuntu, macOS, Win10), just not when running the entire folder. Seems fine to land next week.

the display resolution is 1920x1080 and the scale factor :125 (on MSI A11SB)

Flags: needinfo?(sas.kunz)

Thinking about this more, I'm closing the bug to reflect that the actual fix did land (which will also make uplift tracking easier as we're going into RC week). We can either land the test here still or spin that off into another bug - whatever you prefer, Paul.

Group: firefox-core-security → core-security-release
Status: ASSIGNED → RESOLVED
Closed: 11 months ago
Keywords: leave-open
Resolution: --- → FIXED
Target Milestone: --- → 114 Branch
Whiteboard: [reporter-external] [client-bounty-form] [verif?] → [reporter-external] [client-bounty-form] [verif?][adv-main113+]
Whiteboard: [reporter-external] [client-bounty-form] [verif?][adv-main113+] → [reporter-external] [client-bounty-form] [verif?][adv-main113+][adv-ESR102.11+]
Flags: qe-verify+
QA Whiteboard: [qa-triaged]
Attached image perm_00.gif

Reproduced the issue with Firefox 111.0.1 and 112.0.2 on Windows 10x64 by following steps from comment 0 while the browser was fullscreen. The location access is granted after clicking the Try it button multiple times.
I can no longer reproduce the issue by following the above steps while fullscreen with Firefox 113.0RC1, 102.11.0esr and Firefox 114.0a1 (2023-05-01) on macOS 12, Windows 10x64 and Ubuntu 20.04.

However just to be safe of the current behavior here. Before this patch, the permission door hanger was moved under the address bar after clicking the Try It button. Therefore, clicking multiple times will allow the location permission in this case. On the latest builds the permission door hanger is displayed on the top-left side of the screen after following the steps from comment 0. Is this the expected behavior or should I look for something else in order to verify this issue? (attached a screen rec from win10x64)

Also as a side note on Ubuntu 20.04 the permission door hanger is still moved under the address bar for 113.0RC1 and Firefox 114.0a1 (2023-05-01) but the issue cannot be reproduced. Clicking multiple times will result in checking/unchecking the Remember this decision option. Is this expected? Thank you in advance!

This is the behavior on Ubuntu 20.04.

The patch does not change the location of the PopupNotification doorhanger. The fact that it gets anchored weirdly after a fullscreen exit is a pre-existing bug (I can't find the bug right now). For this bug we're mostly concerned about bypassing the security delay, so if you can't get the notification buttons to line up with the try-it button I recommend testing it like this:

  1. Set security.notification_enable_delay to 5000 (5 seconds) via about:config
  2. Restart the browser for the pref to apply
  3. Use the PoC code and spam the try-it button in full-screen until the notification is shown.
  4. Quickly click the "allow" button of the notification

With patch:
Within the 5 seconds window after fullscreen exit the button should not close the notification. After 5 seconds it should work as usual and close the notification, granting the requested permission.

Without patch:
Click on the button directly closes the notification (also before the 5 second timer runs out)

Flags: needinfo?(pbz) → needinfo?(alexandru.trif)

Oh, I understand now. Thank you very much for the detailed information. I have managed to reproduce the issue by following the str from comment 41 on Windows 10x64 with Firefox 112.0.2 and 113.0a1 (2023-04-03) by having the button aligned and unaligned with the Try It button. The permission can be granted before reaching 5 seconds after spamming the try-it button in fullscreen.

The issue is verified fixed with Firefox 113.0RC1, 114.0a1 (2023-05-01) and 102.11.0esr on Windows 10x64, macOS 12 and Ubuntu 20.04. The permission is no longer confirmed after spamming the try-it button in fullscreen and then clicking the allow button of the notification before reaching 5 seconds.

Status: RESOLVED → VERIFIED
Has STR: --- → yes
QA Whiteboard: [qa-triaged]
Flags: qe-verify+
Flags: needinfo?(alexandru.trif)
Flags: sec-bounty? → sec-bounty+
Summary: Clickjacking to allowed location permission → Clickjacking to allowed location permission (bypassing button-enable delay)
Attached file advisory.txt
Alias: CVE-2023-32207

is there any decision how many bounties that i receive?

Flags: needinfo?(dveditz)
Flags: needinfo?(dveditz)
Regressions: CVE-2023-4047
See Also: → 1840785
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: