1871217 - Android-permission prompt obscured fullscreen notification lead to spoof

Status: VERIFIED FIXED

(Fenix :: General, defect, P1)

Description

[Hafiizh]

Attachment: permissionfullscreen.html

I found a vulnerability in firefox android where a microphone permission prompt can cover fullscreen notifications which can lead to spoofs.
steps to produce

1 . open https://103.186.0.20/permissionfullscreen.html or permissionfullscreen.html
2. click the button.
OS: Android 12 (Samsung M31)

Comment 1

[Hafiizh]

Attachment: document_6061956479827578398.mp4

Comment 2

[Chris Peterson [:cpeterson]]

Titouan's fix for bug 1874795 is expected to also fix this bug. Assigning this bug to Titouan as a reminder to test this bug's STR.

Comment 4

[Titouan Thibaud [:titouan]]

We had some hard time reproducing this bug reliably.
Here is the STR that works for us:

1. Open about:config and set media.devices.insecure.enabled and media.getusermedia.insecure.enabled to true
2. Make sure Fenix has Microphone permission set as "Always ask" (from the device's app settings)
3. Force Quit Fenix
4. Open Fenix and navigate to the HTML attachment. (an other solution is to serve this file with python3 -m http.server and access it from your device)
5. Click on the "Click" button.

We should then see the Fenix permission request (Android level), click "Only one", then see the website permission request.

The website is already in fullscreen and the snackbar was never visible.

Comment 5

[Titouan Thibaud [:titouan]]

The problem we see is: in the case of the HTML attachment provided, the webpage asks for fullscreen and then requests the Microphone permission.

So, at the time our code processes the Fullscreen request, we have no way to know that there's a Microphone permission request coming.

An option might be to have a kind of time threshold where we wait some defined amount of time (x seconds) before going fullscreen, so that we can process permission requests in that time. But we think that the issue would still exist, the website would only have to wait for x seconds before requesting the permission. (Unless we show a kind of warning that you're about to go fullscreen before really going fullscreen).

Another option would be to show the Fullscreen notification somewhere else on the screen, so that we make sure it's visible.

Is there something we are missing? 
Does someone have an opinion on how to correctly handle this case?

Comment 6

[Polly [:polly]]

We think we have 2 possible avenues to explore here:

1. Do What Chrome Android Does
   Go fullscreen when asked, but don't ask for permissions when fullscreen.
   (NB This could be tricky to implement as we have already looked at this. The previous fix will ignore the site permission request if there is already a dialog showing for full screen permissions. Maybe we could extend this to also look for any pending full screen requests, and just bin the permission request entirely if we are about to go fullscreen?)
2. Do What FF Desktop Does
   Go fullscreen when asked, then if asked for a permission, revert to not full screen and show the permission request.

Comment 7

[Titouan Thibaud [:titouan]]

Hey :owlish and :dveditz, does any of you have an opinion on what would be the right resolution for this bug? 

(:skhan suggested both of you might be helpfull here)

Comment 8

[Titouan Thibaud [:titouan]]

Attachment: Bug 1871217: Improve permission handling in Fullscreen

Comment 9

[Polly [:polly]]

We've gone ahead with option 2, reasoning being:

• it is consistent with ff desktop
• it is more resilient to timing issues than just checking for the existence of the notification dialog
• users might need to action the permission request for the best fullscreen experience, eg. if they are in a video call and need to give microphone permission

Patch is attached above, we also have a unit test that we can submit later

Comment 10

[Titouan Thibaud [:titouan]]

Comment on attachment 9395506 [details]
Bug 1871217: Improve permission handling in Fullscreen

Security Approval Request

• How easily could an exploit be constructed based on the patch?: We think it wouldn't be easy, as the STR we know depends on steps which are not referenced in any way in the patch.
  Even if they knew how to exploit the breach, it seems hard to take advantage of it, mainly because they would need to reproduce the UI of Firefox + the Android Status bar for the specific phone so that they can fool the user into thinking they are not in fullscreen.
• 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, Release, ESR. Status reflects that correctly.
• 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?: Very easy, we just need to create the backport
• How likely is this patch to cause regressions; how much testing does it need?: We think it's not very likely to cause regression.
  It would be good to have some testing around fullscreen and permissions in general.
• Is the patch ready to land after security approval is given?: Yes
• Is Android affected?: Yes

Comment 11

[Daniel Veditz [:dveditz]]

Comment on attachment 9395506 [details]
Bug 1871217: Improve permission handling in Fullscreen

sec-approval=dveditz

thanks for waiting while we got the 125 release out. We'll want to uplift this one to beta

Comment 12

[Titouan Thibaud [:titouan]]

Attachment: Bug 1871217: Improve permission handling in Fullscreen

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

Comment 13

[Phabricator Automation]

beta Uplift Approval Request

• User impact if declined: A security issue remains there while the code ships in version 126
• Code covered by automated testing: no
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: Follow the STR on Bugzilla
• Risk associated with taking this patch: low
• Explanation of risk level: small change, but as it's a security bug, the patch hasn't baked in Nightly before this uplift
• String changes made/needed: No
• Is Android affected?: yes

Comment 14

[Donal Meehan [:dmeehan]]

:tthibaud adding a reminder next week is the final week of Beta for Fx126.
This will need to land in central before Thursday 2024-05-02 so we can uplift it by the final 126 beta build.
If not earlier since this already has sec-approval.

Comment 15

[Titouan Thibaud [:titouan]]

Is there a prefered day for landing? If I understand correctly I should land it as close as possible to Thursday 2024-05-02, so I guess Wednesday 2024-05-02 would be the best? Or is there something I'm missing?

Comment 16

[Donal Meehan [:dmeehan]]

It's up to the sec team to communicate if there are any concerns around timing with landing.
I don't see anything mentioned when they granted sec-approval, that they had concerns or direction on when to land.

At least by Wednesday 2024-05-02 works in terms of uplifting on Thursday before the final beta build.

Comment 17

[Titouan Thibaud [:titouan]]

:dveditz, do you have any direction we should follow for landing the patch?

Comment 18

[Chris Peterson [:cpeterson]]

Priority P1 because this bug has been assigned to a squad/group.

Comment 19

[Daniel Veditz [:dveditz]]

no additional instructions beyond the sec-approval. Land as soon as you can unless we explicitly give you a date to wait until.

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/55189bb1efab
Improve permission handling in Fullscreen r=android-reviewers,twhite

Comment 21

[Titouan Thibaud [:titouan]]

The uplift patch is still pending release-managers group approval.
As the first patch is already in the landing queue now, is there something else we should do to get the uplifiting approval?

Comment 22

[Donal Meehan [:dmeehan]]

(In reply to Titouan Thibaud [:tthibaud] from comment #21)

The uplift patch is still pending release-managers group approval.
As the first patch is already in the landing queue now, is there something else we should do to get the uplifiting approval?

No nothing else for you to do, we don't uplift until after it lands in central.
Uplifts for security bugs follow the same process as regular uplift requests. It doesn't get approved until we process the uplift.

Comment 23

[Titouan Thibaud [:titouan]]

Thanks a lot for the explainations!

Comment 24

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

https://hg.mozilla.org/mozilla-central/rev/55189bb1efab

Comment 25

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/d7f460434ca1

Comment 26

[Delia Pop (Android QA)]

Attachment: QA.png

Verified as fixed on the latest Nightly 127.0a1 from 04/30 and Beta 126.0b7. Fenix exits the full screen mode when the website permission dialogue is displayed.
Tested with Samsung Galaxy Note10 (Android 12) and Motorola Moto G30 (Android 12).

Comment 28

[Andrew McCreight [:mccr8]]

tthibaud, in bug 1894326 the reporter says this isn't actually fixed on Android beta. I'm not sure how to reconcile that with the verification in this bug. Can you take a look? Thanks.

Comment 29

[Daniel Veditz [:dveditz]]

Adding explanation for future context

(Titouan Thibaud [:tthibaud] from comment #15)

Is there a prefered day for landing? If I understand correctly I should land it as close as possible to Thursday 2024-05-02 [ed: that is, the last beta this cycle]

(Daniel Veditz [:dveditz] from comment #19)

no additional instructions beyond the sec-approval. Land as soon as you can unless we explicitly give you a date to wait until.

There's a balance between getting real-world testing in beta (or having time to test at all!) and keeping revealing patches out of the public eye as long as possible. Since our release cycles are so short, lack of testing is often a bigger risk than exposure. We prefer people land most security patches as soon as they are ready. As part of sec-approval we will ask that a subset of fixes delay their landing, weighing the severity of the exploit (e.g. zero- or one-click malware or UXSS), the complexity and likelihood of creating an exploit based on the patch, and the fragility (need for testing) of the patched code. In those cases we will explicitly ask that landing be delayed until a specific date/week.

Comment 30

[Daniel Veditz [:dveditz]]

Owlish's needinfo was answered by Polly in comment 9
tthibaud's needinto was moved to bug 1894326

Comment 31

[Jesse Schwartzentruber (:truber)]

Attachment: advisory.txt