1816059 - (CVE-2023-29534) Obscuring the Full-Screen Toast in Android Through the Select Tag

Status: RESOLVED FIXED

(Fenix :: Browser Engine, defect, P2)

Description

[Shaheen Fazim]

Attachment: poc.rar

In the Firefox Android (Fenix) browser, an attacker can conceal full-screen toast notifications using the following method.

I recently reported a similar method that uses a URI to launch an external app prompt to hide the Full-Screen Toast (https://bugzilla.mozilla.org/show_bug.cgi?id=1816007). This is a similar method, but it uses internal HTML elements such as the 'select' tag to obscure the full-screen toast from the victim.

When the victim clicks the button, the following proof-of-concept (POC) triggers the launch of Select Option and Fullscreen simultaneously. This obscures the full-screen toast and loads a spoofed page in the background.

Steps to Reproduce:

1. Download and extract the file poc.rar to a folder
2. Start a Python server on the same folder by running the command python -m http.server 8080.
3. Open the Android Firefox browser and navigate to the server at http://{YOUR-SERVER-IP}:8080/poc.html to Begin testing.

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

Comment 1

[Shaheen Fazim]

Similar Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1259492

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Can this be checked against the Nightly build. The intent should trigger a dialog that the user needs to approve.

Comment 3

[Shaheen Fazim]

I tested the method on the nightly build and confirmed that the select option method does not trigger any dialogs. This vulnerability remains present in the nightly version.

Comment 4

[Daniel Veditz [:dveditz]]

This is not an intent, this is an HTML select widget which is implemented as a floating panel. Would this be a GeckoView bug instead? Or is it the Fenix (and presumably Focus) front-ends that have to know about how select widgets might work?

Comment 5

[Jonathan Almeida [:jonalmeida]]

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

Would this be a GeckoView bug instead? Or is it the Fenix (and presumably Focus) front-ends that have to know about how select widgets might work?

This is a Fenix/Focus front-end bug; something that can be fixed in our shared components layer.

Comment 7

[Petru-Mugurel Lingurar [:petru]]

I'm sorry I only now looked deeply into this.

Seems to me like this is the reverse of https://bugzilla.mozilla.org/show_bug.cgi?id=1819254 which would ensure select prompts would not exit fullscreen.

Chrome seems to also be affected by the scenario described here and the only real "fix" would be to always exit fullscreen for prompts that could take over the entire screen and not enter fullscreen while such a prompt is shown. Which would break important flows the user is accustomed with.

Or we could look into a system in which the fullscreen snackbar is shown on top of everything else, including these prompts (which would probably have to not be implemented as Android Dialogs anymore).

Asking also Emilio for recommendations regarding the prompts and how could we reconcile this and the YouTube issue.

Comment 8

[Petru-Mugurel Lingurar [:petru]]

I was testing on an older Chrome Release which still had this issue.
Based on https://bugs.chromium.org/p/chromium/issues/detail?id=1259492 the problem was resolved and indeed in the latest Canary the issue cannot be reproduced anymore with the provided steps.

What happens now in Chrome Canary is that:

• upon clicking the select the page would enter in fullscreen but
• the prompt would not be opened to cover the fullscreen message
• another click on the select is needed for the prompt to show

Another interesting detail (not sure how new) is that on Chrome a Toast is used instead of a Snackbar and even that on it's own would ensure the message is shown on top of any prompts from the app - this could be a quick fix for Fenix.

Comment 9

[Andrew McCreight [:mccr8]]

Edgar would also be a good person to ask for ideas, as he's dealt with a ton of full screen security issues on desktop.

Comment 10

[Petru-Mugurel Lingurar [:petru]]

Another detail from the current Chrome Canary (new behavior) is that for the YouTube scenario upon closing the select prompt I see the fullscreen message which would suggest they maybe had the same issue with the prompt exiting fullscreen but then the page immediately enters in fullscreen again.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

[NOTE: I wrote this before comment 8 / comment 10, but might still be useful so dropping verbatim]

Yeah, I agree exiting fullscreen is a no-go...

The obvious one is to somehow z-order the fullscreen toast always above prompts. Seems like that would solve it? But it's probably technically complicated...

Desktop fixes this by not allowing the select tag to overlap browser UI.

It seems chromium fixed this by showing the fullscreen toast after the dialogs (or maybe for longer until all dialogs are dismissed?) (see https://bugs.chromium.org/p/chromium/issues/detail?id=1259492#c45). That seems like it might be an acceptable solution?

Comment 12

[Edgar Chen [:edgar]]

Attachment: test.html

I updated the original test and test Chrome Canary a bit with follow steps,

1. click select element to open select promp, but do not select a option immediately.
2. wait page requests fullscreen, prompt will closed automatically.
3. wait fullscreen notification is hidden automatically.
4. click select element again and select one of the options to close the prompt

The behavior I notice is:

• Entering fullscreen closes the existing prompt.
• Fullscreen notification is shown again whenever select prompt is closed, i.e. after step 4. It seems a new behavior as Chrome Release doesn't show notification again after step 4. And I believe it only shows notification, instead of exiting fullscreen and reentering again, since I didn't see additional fullscreenchange event get fired.

I agree that exiting fullscreen whenever a prompt is opened is a bit annoying. And like emilio said, It seems like showing fullscreen notification again while fullscreen content back to foreground is an acceptable solution?

Comment 13

[Petru-Mugurel Lingurar [:petru]]

Attachment: Selecting.mp4

Tested a bit more to understand what overall improvement can we make while also offering a consistent UX for users.

I see that Chrome does two things differently and we should probably do the same.
Based on the attached video:

• show a toast vs a snackbar
  This allows Chrome to show the fullscreen message on top of everything else.
  This is something that we could easily do in Fenix (if approved by product and UX) but unfortunately styling options are non-existent for toasts and with Fenix using multiple snackbars all throughout the app this message will seem a bit out of place.
  If we want to keep using snackbars the groundwork for showing them on top of any other Views was already done in https://bugzilla.mozilla.org/show_bug.cgi?id=1812518 and so we know it's possible. Medium size refactoring.

• the following line
  <select id="mySelect" onclick="document.documentElement.requestFullscreen();"
  does only one thing at a time:

  • first click will execute the onClick method
  • another click is needed to show the select prompt.

Seems like they don't allow both actions at a time while Fenix does. Maybe this is something that can be implemented in Gecko also?
Regarding this scenario it seems like there is 2-way communication betwqeen the engine and the app: if after the first click that triggers entering in fullscreen the user exits this mode then the second screen will again enter fullscreen. I think this would significantly add to the complexity of the implementation.

Comment 14

[Joe M [:jmahon]]

Thanks for the thorough investigation, all. Joining in here after a 1:1 conversation with Petru - my recommendation would be to solve this quickly by updating the Snackbar to a Toast, and creating a follow-up ticket for any potential UX enhancements that we can work through with the design team. I've created a follow-up bug (bug 1822140) for that; Petru, would you mind adding any relevant information over there?

Since this is a sec-high issue, I'm a bit worried about introducing more complexity into the solution than is absolutely necessary.

Comment 15

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug_1816059_-_Show_the_notification_for_entering_fullscreen_as_a_Toast.patch

A Toast ensures the message will be shown on top of anything else.

Comment 16

[Petru-Mugurel Lingurar [:petru]]

Attachment: FullscreenToast.mp4

Showing the updated UX with a Toast instead of a snackbar.

Comment 17

[Jonathan Almeida [:jonalmeida]]

Comment on attachment 9322970 [details] [diff] [review]
Bug_1816059_-_Show_the_notification_for_entering_fullscreen_as_a_Toast.patch

r+ from engineering; this fix is clean and safe to uplift.

Comment 18

[Petru-Mugurel Lingurar [:petru]]

Attachment: Bug_1816059_-_Show_the_notification_for_entering_fullscreen_as_a_Toast.patch

Also doing the same for Focus.

Comment 19

[Petru-Mugurel Lingurar [:petru]]

Comment on attachment 9322994 [details] [diff] [review]
Bug_1816059_-_Show_the_notification_for_entering_fullscreen_as_a_Toast.patch

Security Approval Request

• How easily could an exploit be constructed based on the patch?: While it's an important change from an UX standpoint and might get some attention there is no clear indication about scenarios to exploit.
• 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 but 111 which had a temporary fix in #1798798
• 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?: Given how small the patch is the same code can be uplifted.
• How likely is this patch to cause regressions; how much testing does it need?: Small, straightforward change. Don't expect any issue from it.
• Is Android affected?: Yes

Comment 20

[Petru-Mugurel Lingurar [:petru]]

Added here more recent issues about prompts covering the fullscreen Snackbar.
These all would be fixed by showing a Toast instead of the current Snackbar.

Comment 21

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Comment on attachment 9322994 [details] [diff] [review]
Bug_1816059_-_Show_the_notification_for_entering_fullscreen_as_a_Toast.patch

Approved to land and uplift.

Comment 22

[BMO Github Automation]

Attachment: [mozilla-mobile/firefox-android] Bug 1816059 - Show the notification for entering fullscreen as a Toast (#1260)

Comment 23

[BMO Github Automation]

Authored by https://github.com/Mugurell
https://github.com/mozilla-mobile/firefox-android/commit/01042630c06dd25d529aa7edd73de1172676361a
[main] Bug 1816059 - Show the notification for entering fullscreen as a Toast

Comment 24

[Ryan VanderMeulen [:RyanVM]]

Go ahead and create the v112 backport PR and request Beta approval whenever you're comfortable doing so.

Comment 25

[BMO Github Automation]

Attachment: [mozilla-mobile/firefox-android] Bug 1816059 - Show the notification for entering fullscreen as a Toast (backport #1260) (#1278)

Comment 26

[Petru-Mugurel Lingurar [:petru]]

Comment on attachment 9323463 [details] [review]
[mozilla-mobile/firefox-android] Bug 1816059 - Show the notification for entering fullscreen as a Toast (backport #1260) (#1278)

Beta/Release Uplift Approval Request

• User impact if declined: URL spoofing is possible through hiding when the webpage enters fullscreen.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Small change, just about how a certain message is shown.
• String changes made/needed:
• Is Android affected?: Yes

Comment 27

[BMO Github Automation]

Authored by https://github.com/mergify[bot]
https://github.com/mozilla-mobile/firefox-android/commit/e2ae2a040d1990cbc775bec5715aebd690cbe4a3
[releases_v112] Bug 1816059 - Show the notification for entering fullscreen as a Toast (#1278)

Comment 28

[Dianna Smith [:diannaS]]

Comment on attachment 9323463 [details] [review]
[mozilla-mobile/firefox-android] Bug 1816059 - Show the notification for entering fullscreen as a Toast (backport #1260) (#1278)

Approved for Mobile 112.0b3

Comment 29

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: advisory.txt