1836786 - (CVE-2024-6605) Fenix did not implement "enablement delay" on permission prompts or other dangerous UI that overlay the content area (Tapjacking Permission Using Fullscreen on Android)

Status: VERIFIED FIXED

(Firefox for Android :: Browser Engine, defect, P2)

Description

[Shaheen Fazim]

Attachment: poc.html

Usually, Firefox requires two clicks to grant access when the Permission Dialogue is spoofed. However, on Android Firefox, this implementation is not present because the Permission Dialogue typically doesn't work with new tabs or pop-ups. However, by using an engaging game in Fullscreen mode, an attacker could Clickjack the victim into unknowingly allowing permissions such as Camera, Audio, or Location, etc.

Steps to Reproduce:

1. Download the file poc.html to a folder.
2. Host the file on an HTTPS site.
   Open the Firefox browser on your Android device and navigate to the site at https://{YOUR-SITE}/poc.html to begin testing.

Comment 1

[Shaheen Fazim]

Video Demonstration: https://youtu.be/gdS7KWKUen4 (YouTube Unlisted)

Comment 2

[Shaheen Fazim]

Similar issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1826116

Comment 3

[Shaheen Fazim]

Attachment: chrome permission.mp4

A different solution would be to introduce a delay between taps on the DOM and the allow button. Here's how the Chrome permission dialogue works to prevent tapjacking:

Comment 4

[Shaheen Fazim]

Attachment: poc used for chrome.html

Comment 5

[Shaheen Fazim]

You can modify the CSS values of top and left within the #redBox to adjust the coordinates to align with the Permission buttons.

Comment 6

[Daniel Veditz [:dveditz]]

I believe bug 1836921 and 1836939 will be fixed by this one since they all use the same dialog class

Comment 7

[Daniel Veditz [:dveditz]]

(In reply to Shaheen Fazim from comment #3)

A different solution would be to introduce a delay between taps on the DOM and the allow button. Here's how the Chrome permission dialogue works to prevent tapjacking:

Yes, that's what is supposed to happen, and what the Desktop client and the old "Fennec" android client did. See bug 162020

Comment 8

[Daniel Veditz [:dveditz]]

Updated the summary to reflect the core problem so we're not overly distracted by the specific example demonstrated in this POC.

Comment 9

[Shaheen Fazim]

Thanks, I hope this gets fixed for the next release.

Comment 10

[Shaheen Fazim]

Friendly ping

Comment 11

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

The severity field for this bug is set to S3. However, the bug is flagged with the sec-high keyword.
:jonalmeida, could you consider increasing the severity of this security bug?

For more information, please visit BugBot documentation.

Comment 12

[Shaheen Fazim]

Hi, friendly ping.

Comment 14

[Frederik Braun [:freddy]]

This bug has been stale for a long while. Was this intentionally not included in your security triage, bclark?

Comment 15

[Shaheen Fazim]

Friendly ping.

Comment 16

[Shaheen Fazim]

Hi, it's been a long time. Can we update on this issue?

Comment 17

[Shaheen Fazim]

Friendly ping.

Comment 18

[Shaheen Fazim]

Hi boek (Triage Owner),

Could you please provide an update on this bug? It's been sitting here without an update for a very long time, and it's a security issue.

Comment 19

[[:owlish] 🦉 PST]

Hi Shaheen, we do our best to fix all the bugs in Firefox. Unfortunately, there is only so much bandwidth we have. Thank you for your patience. If you have a question about the bounty for this bug, feel free to email [e-mail]

Comment 20

[[:owlish] 🦉 PST]

Clearing priority and severity to re-triage

Comment 21

[Chris Peterson [:cpeterson]]

Arturo, the Android security triage is assigning this sec-high bug to squad 2. This issue blocks tapjacking meta bug 1842064.

https://mozilla-hub.atlassian.net/browse/FXDROID-660

Comment 22

[Arturo Mejia [:amejia]]

Checking the desktop implementation to get more context and see what will be the approach in Android.

Comment 23

[Arturo Mejia [:amejia]]

Adding @pbz as he was addressing similar issues on Desktop.

I wonder if instead of adding a possible solution to the Android layer (UI or GV), we have an unified solution on the Gecko layer (No to the UI), so all platforms will benefit from it and we have a consistent behaviour (Eventually we are going to have GV on iOS).

Is this is something possible @pbz? Or should I just create a similar solution on Android? Maybe we could delay the sending the message for a prompt in the Gecko layer?

Thanks in advance!

Comment 24

[Arturo Mejia [:amejia]]

I guest the best security approach is to have logic directly on the UI, as it's suggested here

Comment 25

[Emma Zühlcke [:emz]]

Agreed, I think this belongs into the UI code. See if the behavior we have on desktop works well for touch, if not you might have to adapt it.

Comment 26

[Arturo Mejia [:amejia]]

Attachment: Bug 1836786 - Improve prompts

Comment 27

[Arturo Mejia [:amejia]]

Attachment: Bug 1836786 - Improve prompts test

Depends on D214307

Comment 28

[Arturo Mejia [:amejia]]

Comment on attachment 9408500 [details]
Bug 1836786 - Improve prompts

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Not that easy, changes have been separated to make it less obvious
• 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 branches (beta, release, and/or ESR) are affected by this flaw, and do the release status flags reflect this affected/unaffected state correctly?: beta, and release
• If not all supported branches, which bug introduced the flaw?: None
• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?:
• How likely is this patch to cause regressions; how much testing does it need?: Low provability
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 29

[Arturo Mejia [:amejia]]

Patches have been approved!
We are just waiting on the sec-approval.
Thanks in advance!

Comment 30

[Daniel Veditz [:dveditz]]

From the phabricator discussion: the refactoring of PromptAbuserDetector was split out of this bug and into bug 1903828. This bug now "depends on" that one.

We don't like to check in tests that reveal the security bug until a release cycle or so after the patch ships (mid-August in this case assuming the fix it is Firefox 128 shipping July 9). Will you have to fix existing tests when this bug or bug 1903828 lands? Or is all of the changes in this test patch just to test this bug? I would guess that if you have to fix up any tests that should be bundled into the patch for bug 1903828 so that doesn't get backed out.

Comment 31

[Daniel Veditz [:dveditz]]

Comment on attachment 9408500 [details]
Bug 1836786 - Improve prompts

sec-approval+ = dveditz. Please request uplift to the beta branch after a few nightlies of testing to make sure the patch works. (we'll also have to request beta uplift of bug 1903828)

Comment 32

[Arturo Mejia [:amejia]]

Will you have to fix existing tests when this bug or bug 1903828 lands? Or is all of the changes in this test patch just to test this bug?

As we just move PromptAbuserDetector to another package previous tests are still working, not need to fix up.

For Bug 1836786 - Improve prompts we are planing to land D214311 after the bug is addressed and safe to disclose tests.

Comment 33

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/84ada3a6e7a7
Improve prompts r=gl

Comment 34

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9815696341a1
Backed out 2 changesets (bug 1836786, bug 1903828) for causing AC-android failures in SitePermissionsDialogFragmentTest CLOSED TREE

Comment 35

[Arturo Mejia [:amejia]]

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

From the phabricator discussion: the refactoring of PromptAbuserDetector was split out of this bug and into bug 1903828. This bug now "depends on" that one.

We don't like to check in tests that reveal the security bug until a release cycle or so after the patch ships (mid-August in this case assuming the fix it is Firefox 128 shipping July 9). Will you have to fix existing tests when this bug or bug 1903828 lands? Or is all of the changes in this test patch just to test this bug? I would guess that if you have to fix up any tests that should be bundled into the patch for bug 1903828 so that doesn't get backed out.

There were a couple of UI tests that needs to be addressed, for the moment I just disabled them as in Bug #1903828, as fixing them will reveal exploit. I'll try to re-enable them on D214311.

Try to land again.

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c551f8b4c6a6
Improve prompts r=gl

Comment 37

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/mozilla-central/rev/c551f8b4c6a6

Comment 38

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

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

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

For more information, please visit BugBot documentation.

Comment 39

[Arturo Mejia [:amejia]]

Waiting for QA verification before uplifting.

Comment 40

[Donal Meehan [:dmeehan]]

(In reply to Arturo Mejia [:amejia] from comment #39)

Waiting for QA verification before uplifting.

:amejia fyi the last beta uplifts for the Fx129 cycle are tomorrow, so I will need an uplift request by tomorrow since this is a sec-high bug.

Comment 41

[Arturo Mejia [:amejia]]

Filed the request via Lando, the revision is been issued https://phabricator.services.mozilla.com/D214975 but hasn't been linked to this bug.

Comment 42

[Arturo Mejia [:amejia]]

Attachment: Bug 1836786 - Improve prompts

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

Comment 43

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Users will continue be exposed to the exploit
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: See comment https://bugzilla.mozilla.org/show_bug.cgi?id=1836786#c0
• Risk associated with taking this patch: Low
• Explanation of risk level: We are just using a component that was already created before for other prompts
• String changes made/needed: No
• Is Android affected?: yes

Comment 44

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: Users will continue be exposed to the exploit
• Code covered by automated testing: no
• Fix verified in Nightly: yes
• Needs manual QE test: no
• Steps to reproduce for manual QE testing: See comment https://bugzilla.mozilla.org/show_bug.cgi?id=1836786#c0
• Risk associated with taking this patch: Low
• Explanation of risk level: We are just using a component that was already created before for other prompts
• String changes made/needed: No
• Is Android affected?: yes

Comment 45

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/061a74d2643a

Comment 46

[Shaheen Fazim]

Thank you for the fix and bounty.

Comment 47

[Delia Pop (Android QA)]

Attachment: media_20240708_182336_2188498697591402820.mp4

Hi, Arturo,

Apologies for not working on this sooner, but as this ticket was flagged as a security issue, it wasn't included in out "qe-verify+" list.

Could you clarify what's the expected result after tapping the "Click to play" button on the poc.html page?
I've tested this on the latest Nightly 129.0a1 07/08, Beta 128.0b9 and RC 128.0 build 2 with Xiaomi Redmi Note 8T (Android 11) and I've noticed 2 behaviors:

• 1. after entering the full screen mode, the permission dialogue is not displayed after tapping the red button for 6+ times.
• 2. after entering the full screen mode, the permission dialogue was displayed after tapping the red button for 6+ times, and the user can interact with it.
     Additionally, with a high end device, Samsung Galaxy A53 5G (Android 14), the red button was not displayed at all after entering the full screen mode.

Comment 48

[Shaheen Fazim]

Odd. The permission prompt should appear after the click. Is it blocked for this site? If so, you should clear all permissions for the site to start fresh. I'm not sure if new changes have been introduced to block permissions in fullscreen.

Note: It would also work without fullscreen when the address bar is set on top instead of the default bottom in Firefox. If needed, I could make a better proof of concept for this, testing without the fullscreen API.

Comment 49

[Simon Friedberger [:simonf]]

Attachment: advisory.txt

Comment 50

[Shaheen Fazim]

Attachment: test.html

Hi Delia, I just made a new testcase ( test.html ). Can you test this again and see if it is working? Thank you.

Comment 51

[Shaheen Fazim]

Attachment: test-after-fix.mp4

Testing after the fix on version 128.

Comment 52

[Delia Pop (Android QA)]

Attachment: Beta129.0b1.mp4

Thank you, Fazim, for providing the test page and the video recording, that helped a lot!
I managed to reproduce your behavior using the test.html: indeed, the permission dialogue is displayed shortly after interacting with the red button, and there's a significant delay between taps on the button and the taps on the allow button, preventing the user to allow access.
I'll update this ticket as verified.

Comment 53

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

a month ago, dveditz placed a reminder on the bug using the whiteboard tag [reminder-test 2024-08-20] .

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

Comment 54

[Arturo Mejia [:amejia]]

Rebased tests patch and getting ready to land them

Comment 55

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/66de2e90570f
Improve prompts test r=gl

Comment 56

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/66de2e90570f