1786934 - (CVE-2023-37455) In Firefox on iOS, the permission request prompt from the site in the background tab is overlaid on top of the site in the foreground tab.

Status: RESOLVED FIXED

(Firefox for iOS :: General, defect, P2)

Description

[lmarceau]

Originated from bug report https://bugzilla.mozilla.org/show_bug.cgi?id=1784741

Vulnerabilities related to T6

T6-1 : In Firefox on iOS, the permission request prompt from the site in the background tab is overlaid on top of the site in the foreground tab. The permission types in which this vulnerability exists are shown in Table VIII. This vulnerability realizes the Permission-based Phishing Attack shown below. This vulnerability can be exploited in a serious attack that threatens user privacy.

Permission-based Phishing Attack

In a Permission-based Phishing Attack, an attacker compels the target to mistakenly grant access to a resource by presenting a fake permission request. For details on this attack, refer to Sections V-B and VI-B of our paper.
Proof-of-concept Code
We share a proof-of-concept code for overlay of permission request prompts.
https://drive.google.com/drive/folders/1OCA3qSmx-lB-pQB30ky62Xmoi_2BYV4z?usp=sharing

You can try the overlay of the permission request prompt by installing this PoC code on a server on an HTTPS domain.
In particular, open index.html, click on the "Open a New Tab" link, and wait for about 20 seconds.
Then you will see a permission request prompt from the domain where index.html is located on the site "example.com" which is opened in a new tab.

We also prepared a website with PoC installed on our server.
https://pocforshare.com/77cxk/index.html

Comment 1

[Daniel Veditz [:dveditz]]

Laurie: this is a background tab requesting a permission, popping up on top of another tab. This rings a bell and we may have a duplicate for this (or maybe someone filed one on Android in the past that we fixed).

Comment 2

[lmarceau]

Attachment: PoC 1786934.PNG

I can reproduce this issue with the provided PoC.

Comment 3

[lmarceau]

Attachment: PoC 1786934-2.PNG

Ideally would not show if the webview isn't active.

Comment 4

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

The severity field is not set for this bug.
:jeevans, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[lmarceau]

Opened a PR to fix the issue. It implements requestMediaCapturePermissionFor to check if we're the current tab. If it's not the current tab, then the media prompt won't show. This means the media prompt is not going to show on top of another tab when the prompt is requested from a background tab.

Comment 6

[Andrei Bodea[:andrei]]

Hello, Laurie thanks for all the information.
As the information is pretty old, I also checked the pictures and all the messages, and here are my findings:

1. I was able to trigger the Allow "pocforshare.com" to use your microphone - on an older build like v109.

On the latest build v9000 (29027) I had a weird case:

- I opened https://pocforshare.com/77cxk/index.html -> Open a New tab -> Wait for the 20s the prompt is correctly displayed -> Close all the tabs and reach the home-scree -> https://pocforshare.com/77cxk/index.html/second appeared there -> upon accessing that link the Allow "pocforshare.com" to use your microphone was displayed again, and even when pressing Don't Allow when accessing that site, it will appear over and over again. Here is the video In the video you see here, I already tapped on Don't allow so that's why it doesn't appear when opening a new tab.

2. On v9000 (29027) latest nightly build I was able to trigger the correct prompt "Firefox Beta" Would Like to Access the Microphone Firefox uses your microphone to record and upload audio.

Here I had 2 cases:

-Tapping Don't Allow the prompt is dismissed and even with restarts never appeared again.

-Tapping OK the prompt is dismissed and it was never displayed again.

I used: iPhone 13 Pro (15.7.1), iPad mini 5 (14.7), and iPhone 14 (16.1).

I would say if the weird case on the 1. is related only to how our website for the test was made, we can close this one as I verified everything.
@Laurie please let me know if there is something else to test or maybe other websites, I also checked on Chrome, and Safari but there is no prompt displayed with our test website after the 20s so for sure they have nothing implemented.

Comment 7

[lmarceau]

Thanks Andrei. I'll have a look into the case you noted there. My expectation would be that the second prompt (which is only for the website pocforshare.com with the prompt Allow "pocforshare.com" to use your microphone) would show only when we are on the website pocforshare.com, and not shown on top of another tab. I see in your video the prompt appears on top of the homepage (it appears on the correct tab, but navigation to homepage happened afterwards it seems) - I'll have a look into that as this isn't great. The "pocforshare.com" prompt should only show on the "pocforshare.com" website.

Comment 8

[lmarceau]

Opened PR to improve not showing on homepage.

Comment 9

[Andrei Bodea[:andrei]]

Hello, Laurie, please note that the website used for testing is not working anymore can you help with this please?

Comment 10

[lmarceau]

:nomotokazuki Since you originally reported the problem, wondering if it would be possible to have the PoC website available again? That would enable us to test the fix more easily. Thank you for your time!

Comment 11

[Kazuki Nomoto]

I have restored the page, and it is now available.
Thank you for your time!

Comment 12

[Andrei Bodea[:andrei]]

Thank you, Kazuki!
@Laurie as discussed on Slack the issue still occurs.
This appears only if Im on the homepage and tap on the recent visited section.
If I access that website - tap on the button - it opens a new tab with that notification permission - this is correct.
Do you think we can close this issue? I'm not really sure how often it will happen if someone access it from the recent visited.

Comment 13

[lmarceau]

Attachment: RPReplay_Final1686317789.MP4

Hello! I'm attaching the video of this use case here, but I think this use case is acceptable and we fixed the security problem. The prompt only shows when a user clicks to see the "pocforshare" URL. The prompt is not shown when we navigate to "example.com" domain anymore. I attached the video here Andrei shared with me.

cc: :dveditz I think this is fine but what do you think?

Comment 14

[Daniel Veditz [:dveditz]]

Attachment: POC from reporter's site

Comment 15

[Daniel Veditz [:dveditz]]

Attachment: "second.html" required by first stage of the POC

The POC requires a second page. For convenience I've combined the separate .js file into the .html. The referenced style.css was a 404 on the reporter's site but it should be fine since there's nothing on that page to style.

Because it's two files the POC won't run from the bugzilla attachment. You'll have to download both files together. Doesn't matter what the POC is called, but this one has to be "second.html" or you'll have to edit the POC. Might work as a local file: url, but you might have to run a localhost server (e.g python3 -m http.server or node or similar)

Comment 16

[Daniel Veditz [:dveditz]]

oh, permissions won't work from an insecure context. A simple server isn't going to have a cert so you can't load the test from a desktop server, and while Chrome and Firefox otherwise consider http://localhost to be a "secure context", webkit does not so that won't work either.

Comment 17

[Daniel Veditz [:dveditz]]

The video is OK for --this-- permission prompt, but it looks like the patch is specific to the media devices prompt. Could someone turn around and do the same thing with prompts for other permissions? If they don't share common base code that prevents them from appearing in front other the wrong tab then we have to look at each one at a time, and hope we don't forget one.

Comment 18

[Daniel Veditz [:dveditz]]

I tried rewriting the testcase to run in a single file from the bugzilla attachment, but I don't know the purpose of navigating to the second page. Is there a reason the permission request has to be done after a navigation rather than from the original document? The setTimeout() makes sense -- you have to give time for the victim page to load.

In fact I don't see how requesting the permission after the navigation is valid in the first place, with or without the popup. Permission prompts are supposed to be limited to "user activation", and the user didn't click in that page -- they clicked in the previous page. Not to mention the 10 second delay between the click and the attempted action violates the "no surprises" principle of requiring the click. See, for example, the "popup" vs "popup (delayed)" tests on https://permission.site/, which Firefox for iOS does correctly (blocks the delayed popup). [Note: this site includes tests for several chrome-only features that aren't expected to work in Firefox]

Looks like getUserMedia() might be a special snowflake wrt requiring user activation, see still-open Enforcing user gesture for getUserMedia
. Comments in that thread confirm that in Safari, user-activation isn't inherited across navigations. But apparently getUserMedia() doesn't require user activation. I guess the user's ability to block future requests disincentivizes abuse.

Comment 19

[lmarceau]

Could someone turn around and do the same thing with prompts for other permissions?

:dveditz the media prompt includes camera and microphone permissions, as seen with WKMediaCaptureType.

For other iOS permissions type, like location permissions; it's a different flow which we don't really have as an API for to control over (so no equivalent of webView(:requestMediaCapturePermissionFor: that I used here to improve on this flow). We do have some improvements to do with the location permission thought with 1786929, 1786931 and 1786932. I don't think WebKit can ask for other permissions than those 3.

Comment 20

[lmarceau]

Hello I will close the current issue as fixed, but we opened two related bugs with 1840921 and 1840919.

Comment 21

[lmarceau]

Attachment: advisory.txt