1816007 - Obscuring Full-Screen Toast in Android Through Google Assistant URI

Status: RESOLVED FIXED

(Firefox for Android :: Browser Engine, defect)

Description

[Shaheen Fazim]

Attachment: poc.rar

In Firefox, an Attacker Can Conceal Fullscreen Toast Notifications.

This vulnerability is similar to recently fixed Chromium bugs, such as https://bugs.chromium.org/p/chromium/issues/detail?id=1370028 and https://bugs.chromium.org/p/chromium/issues/detail?id=1320538. Although Android Firefox is not vulnerable to the method used in these bugs, I have discovered a different method where the attacker can achieve the same result.

When the victim clicks the button, the following proof-of-concept (POC) triggers the launch of Google Assistant using an Android URI. 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/uhofqP649_o (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 this method on the nightly build and found that the URI intent method triggers a dialog that requires user approval.

Comment 4

[Shaheen Fazim]

However, after approval on the nightly build the issue remains, where the full-screen toast notifications are being obscured by the intent. With the current POC code, full-screen launches directly with the dialog, but we could delay the launch of full-screen by increasing the timeout, thus providing the user with sufficient time to approve the intent before launching the full-screen.

Comment 5

[Shaheen Fazim]

Here is a video testing the Nightly build of Fenix: https://youtu.be/watch?v=NO8rr4R2gGM (YouTube Unlisted)

I have set the timeout to 2500 and modified it to provide users with sufficient time to approve the intent before launching the full-screen, successfully hiding the notification toast if the user approves the intent on Nighty version of Fenix.

Note: It is also possible to delay the fullscreen using setTimeout Funtion, I am uncertain if this constitutes a problem.

Comment 6

[Daniel Veditz [:dveditz]]

I guess this could be a problem with any intent that goes to any app with "draw on top" permission that draws in that part of the screen. The solution is the same as bug 1816287 -- if we send focus away we should exit (or not enter) fullscreen mode. I don't know if this would be handled in possibly in-common Gecko code, or if these two bugs are two separate fixes.

Comment 7

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

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

For more information, please visit auto_nag documentation.

Comment 8

[Shaheen Fazim]

If the bug severity is currently set to "moderate" because the user requires a special app intent to exploit it, I would like to draw attention to the fact that an attacker could also exploit the bug by targeting any URI, for example URI's such as "mailto:" and "geo:", on an Android device where the user has installed multiple apps. When the URI is opened, an "Open with" dialogue box may appear, which can potentially hide the full-screen toast as well. Therefore, I would like the team to re-evaluate this report with the possibility of a higher severity rating, if appropriate.

<a href="mailto:" onclick="run();">test Mailto</a>
<a href="geo:" onclick="run();">test Geo</a>
<script>
    function run() {
        setTimeout(function() {
            document.documentElement.requestFullscreen();
        }, 500);
    }
</script>

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

Comment 9

[Shaheen Fazim]

(In reply to Shaheen Fazim from comment #8)

If the bug severity is currently set to "moderate" because the user requires a special app intent to exploit it, I would like to draw attention to the fact that an attacker could also exploit the bug by targeting any URI, for example URI's such as "mailto:" and "geo:", on an Android device where the user has installed multiple apps. When the URI is opened, an "Open with" dialogue box may appear, which can potentially hide the full-screen toast as well. Therefore, I would like the team to re-evaluate this report with the possibility of a higher severity rating, if appropriate.

<a href="mailto:" onclick="run();">test Mailto</a>
<a href="geo:" onclick="run();">test Geo</a>
<script>
    function run() {
        setTimeout(function() {
            document.documentElement.requestFullscreen();
        }, 500);
    }
</script>

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

Correction: I meant "security rating" instead of "severity"

Comment 10

[Shaheen Fazim]

Here, an attacker can use commonly used URI intents such as Google Assistant or URIs like mailto: or geo: thus Multiple apps may trigger a choose dialogue or in the future a different intent could be triggered with a new method. Therefore, I suggest a better fix would be to block all URI intents from loading with the full-screen API.

Comment 11

[Daniel Veditz [:dveditz]]

This appears to be another variation fixed by the change of approach used to address bug 1816059.

Comment 12

[Daniel Veditz [:dveditz]]

The bounty was accounted for in the underlying fix in bug 1816059

Comment 13

[Tom Ritter [:tjr]]

Attachment: advisory.txt