Fenix protects against websites opening too many alert() or prompt() dialogs, similarly to Firefox on desktop. It doesn’t have any such protection for abuse of window.open() calls however. Each call results in a pop-up prompt, with an unlimited number of such calls stacking.

Please take care when opening the attached proof of concept page, the resulting denial of service is difficult to resolve! This page will attempt to open a pop-up every 100 milliseconds, each time resulting in a new prompt. These prompts are too many to be canceled, and the entire Fenix UI becomes unreachable so that switching tabs or reloading isn’t an option. Even if the process is terminated, restarting will restore the tab and load the malicious page again. I could only resolve this via Developer Tools.

Firefox on desktop doesn’t have this issue: its prompts are tab-modal, they don’t block other UI parts. Also, the pop-up prompt is non-modal. And the prompts don’t stack, the existing prompt simply counts up. So all pop-up requests can be dismissed at once.

The prompts functionality in A-C/Fenix needs a bigger refactoring to make popups tab-modal and also support a queue of prompt requests which would then allow for a better popup blocker to be implemented. We should then also inform the user of the number of popups blocked on the current page.

I attached a short-term patch here which makes sure we only show one popup at a time. It also reuses our existing prompt abuse detector so users can disallow any more popups from the current page.

Comment on attachment 9215115 [details] [diff] [review]
0001-Improve-prompt-handling.patch

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Easy to construct a page to trigger the DOS. I kept the tests in the same commit too for now as this is rated sec-low, but please advise if we should land separately.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: Yes, the sec-low DOS attack can likely be inferred from the patch.
• Which older supported branches are affected by this flaw?: All of them
• 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?: Easy to create backports. Risk is low.
• How likely is this patch to cause regressions; how much testing does it need?: Unlikely to cause regressions, but basic testing of popup prompts is required.

Requested sec-approval to double-check as this bug relates to bug 1701684, which does have an independent patch though.

Comment on attachment 9215115 [details] [diff] [review]
0001-Improve-prompt-handling.patch

sec approved

Fix landed in Fenix 89 Nightly 210413 17:00.

https://github.com/mozilla-mobile/android-components/commit/346a44da6c537e73c5343f3aa76a35256f8273fc

Hello Sebastian, can you please help me with the steps in order to verify this issue?

Hey Andrei.

If you open the "Proof of concept page", added as an attachment to this bug, then:

• In an unpatched version of Fenix you should see multiple prompts stack on top of each other asking whether you want to allow the page to open popups. And there will be no real escape from this.
• In a patched version of Fenix the prompts will not stack (only one shown) and follow-up prompts will have a checkbox that allows you to block further prompts from this page.

Thank you for the explanation, Sebastian!

Please note that I'm still able to reproduce this issue on the latest Nightly 4/22 and Latest Beta 89.0.0.b1 with Google Pixel 4 XL (11).
This is the behavior I saw:
No matter how many times I pressed Deny or Allow the prompt was still there.
After I selected Prevent this page from creating additional dialogs and press any of the Deny orAllow` the prompt will go away but after a home button interrupt the prompt is back or using the recent apps button.
Note that the same behavior is on both builds Nightly and Beta.
Gif

There was a misunderstanding about the verification and after I synced with Christian on zoom we agreed that what I said above is the intended behavior.
Based on this comment and my verification from above, I verify this issue as fixed on Nightly 4/22 and Latest Beta 89.0.0.b1 Google Pixel 4 XL (11).
In the GIF above, the intended behavior can be seen.

Thanks, @sebastian and @christian!