1707956 - Firefox for Android Entering Fullscreen Snackbar Notification Spoof using Dialogs or Text Selection Menu

Status: RESOLVED FIXED

(Fenix :: Toolbar, task, P3)

Description

[Irvan Kurniawan [:sourc7]]

Attachment: spoof.1.html

After invoke Element.requestFullScreen() method using JavaScript, Firefox Fenix will show fullscreen snackbar notification with message "Entering full screen mode" so that end user is aware (to prevent spoofing).

Surprisingly I found that Android text selection menu (from Android 6.0) able to overlap Firefox Fenix entering fullscreen snackbar. When user select text from the web, the text selection menu (e.g. Cut, Copy, Paste, Search, and Share) will overlap the Fenix snackbar notification.

On Chrome for Android, the fullscreen notification toast is shown in front of text selection menu, so spoofing/hiding the fullscreen notification toast is not possible.

Version tested:

• Firefox Nightly 90.0a1 Build ID 20210424090050
• Firefox 88.0.1 Build ID 20210426133657

Steps to Reproduce:

1. Visit attached spoof.1.html
2. Tap "Sign in with Google" input element
3. Fullscreen notification overlapped by text selection menu

Comment 1

[Irvan Kurniawan [:sourc7]]

Attachment: Screenrecorder-2021-04-27-23-15-33-329.mp4

Comment 2

[Irvan Kurniawan [:sourc7]]

Attachment: Chrome for Android - Toast Spoof Test

Comment 3

[Kevin Brosnan [Ex-Mozilla]]

Confirmed behavior with bottom toolbar in portrait orientation and in dark mode. The fullscreen text is covered in light mode. The toolbar color switching may clue the user into something odd has happened. The attacker could use prefers-color-scheme to make an intelligent guess here and provide a likely asset. The attack does not work if the user has toolbar set to top. I don't believe web APIs provide any way to detect this preference. The attack does not fully work in landscape mode. I also suspect devices with different aspect ratios may see the entering fullscreen mode text. These flaws could be worked around by the attacker with some wider testing of the attack and additional code.

Comment 4

[Kevin Brosnan [Ex-Mozilla]]

Attachment: top toolbar offset

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

Attachment: light/dark mode difference

Comment 6

[Irvan Kurniawan [:sourc7]]

Attachment: spoof.dialog.html

When call JS method alert() or confirm() on Firefox for Android, it will show the floating message dialog with Android native Dialogs.

I also found that when the requestFullScreen() method called simultaneously with JS dialog alert() or confirm(), the fullscreen snackbar notification is also overlapped by the Android Dialogs.

Comment 7

[Irvan Kurniawan [:sourc7]]

Attachment: Fenix - Snackbar Spoof using Dialog.mp4

Comment 8

[Irvan Kurniawan [:sourc7]]

Attachment: Fenix - Snackbar Spoof using Dialog - Pixel 2.mp4

On some device (reproduced on Pixel 2 API 29 Android Emulator), the fullscreen snackbar is fully overlapped by the Android Dialog, so user won't notice the notification.

Comment 9

[Daniel Veditz [:dveditz]]

Probably "sec-moderate". Will look at some equivalent past Chrome bugs to see if that's the right ball-pack. Seems at least a little worse than a sec-low spoof (presumably the full-screen image would then contain a fake toolbar)

Comment 10

[Irvan Kurniawan [:sourc7]]

(In reply to Kevin Brosnan [:kbrosnan] from comment #3)

Confirmed behavior with bottom toolbar in portrait orientation and in dark mode. The fullscreen text is covered in light mode. The toolbar color switching may clue the user into something odd has happened.

Thanks Kevin for confirming and the detailed analysis.

The attacker could use prefers-color-scheme to make an intelligent guess here and provide a likely asset.

Yes, with prefers-color-scheme it able to know the user device theme.

The attack does not work if the user has toolbar set to top. I don't believe web APIs provide any way to detect this preference.

I found a workaround to detect this using window.mozInnerScreenY the value differ significantly when the toolbar set to top and set to bottom.

I noticed using a few different phone and Android Emulator when toolbar set to top the mozInnerScreenY value is set above ~80, then when toolbar set to bottom the mozInnerScreenY value is set below ~40. This can be a reliable way to detect the position of the user's toolbar.

The attack does not fully work in landscape mode.

On landscape mode by using spoof.dialog.html it can partially cover the fullscreen notification, however the results is depending on device screen, on smaller screen it can fully cover the fullscreen notification (tested on Android Emulator - 4 WVGA (Nexus S) API 29).

I also suspect devices with different aspect ratios may see the entering fullscreen mode text. These flaws could be worked around by the attacker with some wider testing of the attack and additional code.

Now with spoof using Android Dialogs spoof.dialog.html it can fully cover the fullscreen mode text, which more reliable than text selection menu

Comment 11

[Irvan Kurniawan [:sourc7]]

Attachment: spoof.dialog+mozinnerscreen.html

Following the dialog spoof testcase with added combination of prefers-color-scheme which detect toolbar theme and mozInnerScreenY which detect toolbar position.

Comment 12

[Chris Peterson [:cpeterson]]

sec-moderate -> P3

Comment 13

[Chris Peterson [:cpeterson]]

sec-moderate -> S3

Comment 14

[Chris Peterson [:cpeterson]]

Tasks should have severity N/A.

Comment 15

[Irvan Kurniawan [:sourc7]]

Hi Dan or Tom, I see Firefox on Android is now using Android native Toast instead of Custom Toast view or snackbar.

Last year I've reported to Chrome VRP they do affected by same issue, then they are finally switching back to Android native Toast to fix the issue.

As Firefox on Android already switched to Android native Toast this issue has been fixed. The commit link that fixes the issue is https://github.com/mozilla-mobile/firefox-android/pull/1278, then I look at Mozilla advisory it fixed at "CVE-2023-29534: Fullscreen notification could have been obscured on Firefox for Android".

I hope this one is also rewarded and took same severity because I've reported this very early than Bug 1816059.

Comment 16

[Daniel Veditz [:dveditz]]

So you're saying this is fixed also? (seems to check out)