1942716 - (CVE-2025-6431) Bypass external dialog permission using window.onblur in Android

Status: RESOLVED WORKSFORME

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

Description

[Umar Farooq [:Puf]]

Attachment: Pufindex.html

#Summery

in Android Firefox Attacker can Execute or redirect to malicious intent through User normal activity behaviour for example Tap or Click on Back button in Android or Tap on [ + ] New Tab
this leads bypassing dialog protection and execute malicious intent links

Reproduce Video Unlisted: https://www.youtube.com/shorts/TTLK-jjVT0A

#Steps to reproduce the problem

1. Open Attached PufIndex.html in Firefox Nightly Or Latest Firefox
2. Tap or Click on Back press (or) [ + ] new tab

Results: Successfully Executes Samsung Browser Loading Evil Site

#Firefox version, operating system version:

OS : Android 13
Firefox Version : 136.0a1

Comment 1

[Umar Farooq [:Puf]]

Additional information: if user tap or click on Middle: Home button it will execute intent Successfully

Comment 2

[:Gijs (he/him)]

Does this not reproduce on other browsers? Does the intent link work if it's on a normal <a href>?

Comment 3

[Umar Farooq [:Puf]]

it does not reproduce on Chrome

Comment 4

[Umar Farooq [:Puf]]

Does the intent link work if it's on a normal <a href>?

If a User Click on intent link on normal href Firefox will show External Application dialog

Comment 5

[:Gijs (he/him)]

(In reply to Umar Farooq [:Puf] from comment #4)

Does the intent link work if it's on a normal <a href>?

If a User Click on intent link on normal href Firefox will show External Application dialog

Sarah, do you know why we don't show the dialog in the blur case?

Comment 6

[[:owlish] 🦉 PST]

Hey Devota, do you know the answer to Gijs's question above?

Comment 7

[Umar Farooq [:Puf]]

any update regarding this issue

Thank you

Comment 8

[Umar Farooq [:Puf]]

any update regarding this issue

Thank you

Comment 9

[Umar Farooq [:Puf]]

Hello, just a gentle reminder to keep this Issue on track!
Thank you

Comment 10

[Umar Farooq [:Puf]]

Hi Daniel

I have verified that this Vulnerability has been fixed in the latest Firefox Nightly version 141.0a1 (Bulid #2016093407). I kindly request that you Verify from your side update the status of this bug

Thank you

Comment 11

[Umar Farooq [:Puf]]

Attachment: Screenshot .jpg

I'm able to see the permission dialog after its fixed

Comment 12

[Daniel Veditz [:dveditz]]

I confirm that I can reproduce the bug in Beta 140 and Release 139, and this appears to work correctly ("fixed") in Nightly 141. I don't see any likely fixes in the android bugs resolved in 141 before you noticed it working:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=FIX%20prod%3Aandroid%2Cgeckoview%20status_firefox141%3Afixed%2Cverified%20last_resolved%3C2025-05-29

I looked over the much larger set of changes in shared code and nothing there jumped out at me, either.

Comment 13

[Umar Farooq [:Puf]]

Hi Daniel,

Thank you so much for updating the status,

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

I confirm that I can reproduce the bug in Beta 140 and Release 139, and this appears to work correctly ("fixed") in Nightly 141. I don't see any likely fixes in the android bugs resolved in 141 before you noticed it working:

I would like to inform you that I have verified it has been fixed in the latest Firefox Beta version 140.0b3 (Build #2016093935) too.

Comment 14

[Daniel Veditz [:dveditz]]

Thanks! I can confirm this is fixed as of Beta 140.0b3 (previously I assumed if Release was up to date then Beta was, too, but my phone had decided that I don't use Beta enough and stopped applying updates automatically). That's a whole lot more changes to look through, but the only one that seems at all related to external apps is bug 1929028. Not at all the same bug, but the patch changed a whole bunch of things and quite plausibly affected this.

Roger: do you think your fix for bug 1929028 might have also fixed this one?

Comment 15

[Roger Yang [:roger]]

Yes, that's possible. If the exploit is trying to continue to load the page before user confirms the prompt, Bug 1929028 have removed that possibility. We now wait till user's response of the applinks prompt before decide on loading the page or not.

Comment 16

[Roger Yang [:roger]]

:Puf, I do still have one question, if you set "Open links in apps" setting to "Always", does it still open the URL (I expect it will).
If it does, is this still considered an issue? Thanks

Comment 17

[Umar Farooq [:Puf]]

(In reply to Roger Yang [:royang] from comment #16)

:Puf, I do still have one question, if you set "Open links in apps" setting to "Always", does it still open the URL (I expect it will).
If it does, is this still considered an issue? Thanks

first, I would like to say Sorry for late response I was offline

Answer: it will open, I don't think it is considered an issue because of users changing settings

Comment 18

[Daniel Veditz [:dveditz]]

I'm not entirely sure how this could be used maliciously? If you didn't have the external app at all then we would open the page in the browser. Either that's safe or it's not safe, and if it's not safe that's an entirely different bug. Why is it a problem to load the same URL in two places?

Looking at bug 1929028 that describes exactly what's going on here so it's a duplicate, not an incidentl "fixed by".

Comment 19

[Umar Farooq [:Puf]]

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

I'm not entirely sure how this could be used maliciously? If you didn't have the external app at all then we would open the page in the browser. Either that's safe or it's not safe, and if it's not safe that's an entirely different bug. Why is it a problem to load the same URL in two places?

Looking at bug 1929028 that describes exactly what's going on here so it's a duplicate, not an incidentl "fixed by".

Hi Daniel

This Vulnerability is all about not asking permission to open external app if a use window.onblur=function() {
the Firefox is not showing permission dialog

would like to leave Firefox to view the content? and this leads silently executing external application

Comment 20

[Umar Farooq [:Puf]]

I Have Reference maybe useful information regarding this vulnerability

https://issues.chromium.org/issues/40060327

We have seen a threat actor sending an exploit link. When the user clicks the link in Chrome on Samsung devices, the URL is opened in Chrome. However when the server responded with a 302 redirect, the redirect location was an intent URI string:

intent://<ATTACKER_URL>/#Intent;scheme=https;package=com.sec.android.app.sbrowser;action=android.intent.action.SBROWSER_VIEW_FOR_EXTERNAL_APP;end

This intent URI causes the link to be opened in the Samsung browser (com.sec.android.app.sbrowser) application instead. This occurs without any notification to or consent from the user.

The Samsung browser is currently on Chromium 96.0.4664.104, which was released in December 2021, meaning the attacker could then use a Chromium n-day to exploit the user. Even if a user is choosing to use Chrome for all of their web browsing, without consent or notification, they can be downgraded to an unpatched web browser.

Comment 21

[Umar Farooq [:Puf]]

intent can be seriorus (In reply to Daniel Veditz [:dveditz] from comment #18)

I'm not entirely sure how this could be used maliciously? If you didn't have the external app at all then we would open the page in the browser. Either that's safe or it's not safe, and if it's not safe that's an entirely different bug. Why is it a problem to load the same URL in two places?

When a user clicks on a link that contains external protocol link on a page, first the Firefox will show up permission dialog to open or cancel to ensure the user safety

Example: Open in Samsung Internet

Comment 22

[Umar Farooq [:Puf]]

if an attacker use window.onblur=function() {
this function leads to bypassing dialog protection to open external application and lunch silently external application

1929028 after this fix, this vulnerability also fixed, now the permission dialog is showing on latest version on window.onblur=function() { too

the main concept of this vulnerability
is not showing permission dialog for external application if an attacker use window.onblur function

I think I need to change the title of this vulnerability

Comment 23

[Umar Farooq [:Puf]]

More Ref:

https://bugzilla.mozilla.org/show_bug.cgi?id=1908488

https://bugzilla.mozilla.org/show_bug.cgi?id=1836921

obscure the confirmation prompt shown before launching external apps. This could be used to trick a user in to launching an external app unexpectedly.
This issue only affects Android versions of Firefox.

Comment 24

[Umar Farooq [:Puf]]

Firefox confirms with users whether they want to launch an external application before proceeding, providing protection against these vulnerabilities.

In this proof of concept, where an attacker could execute intent and bypassing dialog permission using window.onblur in Android

this leads bypassing dialog protection and execute malicious intent links

Reproduce Video Unlisted: https://www.youtube.com/shorts/TTLK-jjVT0A

intents are effectively the same kind of evil as external helper apps or external content handlers on Desktop. We shouldn't be loading any that aren't on an explicit whitelist without asking the user first.

Thank you

Comment 25

[Umar Farooq [:Puf]]

Attachment: index.html

I Have Updated proof of concept in this proof of concept Video to show How Serious can be this vulnerability is

New Reproduce Video Unlisted: https://www.youtube.com/shorts/BzDB2YyfS-8

Steps to reproduce the problem

1. Open Attached index.html in Firefox Nightly Or Latest Firefox
2. Tap on address bar or Home Button or Back button

Results: Successfully Executes Caller dialer no permission dialog required

I kindly request you reconsider upgrading severity

https://bugzilla.mozilla.org/show_bug.cgi?id=1836921 = Sec-moderate tapjacking bug but it needs multiple taps but given sec-moderate

Comment 26

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 27

[Umar Farooq [:Puf]]

I Kindly request a re-evaluation of the severity assigned

My reasoning is primarily based on a comparison with a previously addressed similar vulnerability, [1836921 Tapjacking Android dialog to launch intents"], which was categorized as "sec-moderate."

1836921 Tapjacking Android dialog to launch intents = This Bug Requires Many taps to launch intents, but it is considered Sec-moderate

But my Vulnerability requires single tap to launch intent or external protocol

The core issue is that user interaction with standard, seemingly safe browser UI elements (Address Bar, Home Icon, Back button, Tab Menu) can be leveraged to trigger the execution of external protocols

The vulnerability exploits actions that users perform routinely and without suspicion, making it highly effective for tricking victims. A tap on the address bar to edit a URL or a tap on the back button to navigate can inadvertently launch a malicious link.

Since the interaction appears benign (tapping a browser UI element), users are unlikely to suspect a malicious action is taking place, making the attack highly stealthy and effective.

I would appreciate it if the team could kindly re-assess My bug to determine if an upgrade to "sec-moderate" is more appropriate. I am available to provide any further technical details or clarification needed to support this review.

Thank you for your time and consideration.

Comment 28

[Daniel Veditz [:dveditz]]

(In reply to Umar Farooq [:Puf] from comment #20)

I Have Reference maybe useful information regarding this vulnerability
https://issues.chromium.org/issues/40060327

We're aware of that issue. It was tracked by us as bug 1810705 and fixed.

The Samsung browser is currently on Chromium 96.0.4664.104, which was released in December 2021

The Samsung browser apparently lies. If you test recent-ish Chrome security fixes in it they are usually fixed. There's more lag than anyone wants, but it's comparable with their Android OS update lag. My own copy claims to be Chromium 130 so maybe you're on a phone model Samsung stopped updating entirely?

(In reply to Umar Farooq [:Puf] from comment #25)

I Have Updated proof of concept in this proof of concept Video to show How Serious can be this vulnerability is
...<snip>...
Results: Successfully Executes Caller dialer no permission dialog required

We intentionally do not require user interaction for the tel: scheme because it's ubiquitous on the mobile web and users want it to work. The stock dialers from the OS vendors (Google and Apple) are safe. Yes, we're aware that some carriers made extremely bad decisions adding features to their dialers in the past without considering the standards or the security of what they were doing. If anyone is still doing that a decade-plus later it's practically criminal.

bouncing the request for severity re-evluation to Tom

Comment 29

[Tom Ritter [:tjr]]

The tel: external protocol is a bad example; but in the original video it demonstrated a different type of intent, so I will work off that. I agree that this is at least as bad as Bug 1836921 - I'm not entirely sure that is a moderate, but to keep it consistent I would raise this to a moderate as well.

Comment 30

[Umar Farooq [:Puf]]

Thank you.

kindly please update to sec-moderate in advisory

Comment 31

[Tom Ritter [:tjr]]

Thank you for reminding me; done: https://github.com/mozilla/foundation-security-advisories/commit/cd9d668d3dcb91ec1fe56a105e306880077bcc2a