1741817 - URLs with external protocols (or intents) should only open with user-interaction

Status: RESOLVED DUPLICATE of bug 1810705

(GeckoView :: General, defect, P2)

Description

[Kirtikumar Anandrao Ramchandani]

Steps to reproduce:

1. Visit exploit

Actual results:

It will click on behalf of the user and transfer the USSD code to the dialer

Expected results:

It should click on behalf of the user for this specific case.
To know this behavior, you can test this on Chrome and Edge Android, you will find that they will block it because this causes a no-click attack related to USSD.

Comment 1

[Kirtikumar Anandrao Ramchandani]

Adding :
Daniel as he triages issues well.
Annevk as he has worked on few of the tel: URI cases
Kevin as he triaged Bug 1728742

In the Chrome and Microsoft Edge, it will block from the click even if you will use JS in another way to click on behalf of the user, the USSD code will fail in being sent the problem is found in Firefox where it clicks on behalf of the user as well as decodes the USSD code well enough that it is sent completely to the user's dialer. This issue is different from Bug 1728742 as this requires a separate patch but here, we use the courtesy of that case to show the impact as well as to show why Chrome and Edge block it almost all chromium-based browsers have that behavior or example Brave too.

Comment 2

[Kirtikumar Anandrao Ramchandani]

Note: This attack has the same attack scenario as Bug 1728742
Hoping for an urgent patch.

Comment 3

[Daniel Veditz [:dveditz] out until Nov 10]

Attachment: testcase

Comment 4

[Daniel Veditz [:dveditz] out until Nov 10]

Launching external protocols handlers (tel: in this case) or intents should only happen when there's active user interaction -- for the most part these are annoying surprises much like popups. An unusual scheme should also trigger the prompt about whether the user wants to allow that site to launch that kind of service at all, and that, too, can be used to annoy users into submission if it's not gated on user interaction. For pre-approved schemes like tel and mailto the user-interaction requirement puts a break on drive-by exploitation when bad bugs are found in the handlers themselves (such as bug 1728742)

Comment 5

[Kirtikumar Anandrao Ramchandani]

Hi,
Thank you very much for the explanation. This is weird why was this marked as sec-moderate? Even though this issue can be used to perform Banking USSD Attack which is described here: https://bugzilla.mozilla.org/show_bug.cgi?id=1728742#c25
In this case, we're having no click+Banking USSD attack. Still, the severity is set to moderate. Whereas, Bug 1728742 requires one click on the hyperlink. So, we should probably be escalating this case to high (or more than that?) because this requires the user to follow only the link, and the remaining will be done.

Comment 6

[Kirtikumar Anandrao Ramchandani]

Minor correction in Comment 0 of this bug:
Expected behavior: It shouldn't click on behalf of the user for this specific case.

Comment 7

[Daniel Veditz [:dveditz] out until Nov 10]

This is weird why was this marked as sec-moderate? Even though this issue can be used to perform Banking USSD Attack which is described [in bug 1728742 comment 25]

We already have a sec-high bug for the Banking USSD Attack, we don't need two. It's not at all hard for a web page to get you to click on something so the change in this bug is either an anti-annoyance (sec-low) or slightly slows down the other attack which maybe stretches to a sec-moderate. Or put another way, once we fix bug 1728742, how would rate this bug on its own?

Comment 8

[Kirtikumar Anandrao Ramchandani]

If I'll use another way to click on the behalf of the user, I don't see complete USSD code in the dialer, it doesn't get decoded not sure tho why. But this still requires separate patch as this will have a patch where firefox won't click on the behalf of the User unless there is UI?

Comment 9

[Kirtikumar Anandrao Ramchandani]

Friendly ping for Daniel sir to check comment 8. And Kevin sir, can you please check if the folks from Comment 31 of Bug 1728742 can work on this case too? So, we can close this case also which can then help to disclose (blog) both cases together? Thanks in advance. Btw, merry Christmas in advance and happy new year too. Thanks to Mozilla team for protecting mere mortals like us from browser attacks in the year 2021. Keep up the great work! :)

Comment 10

[Roger Yang [:royang]]

This will require a separate patch from https://bugzilla.mozilla.org/show_bug.cgi?id=1728742. We could block the intent if it's not a result of a user interaction; however, this will break legit sites that redirects before launching the external targeted intent.

Comment 14

[Kevin Brosnan [Ex-Mozilla]]

Talked with Christian and this would need some new GV work to chain the user action through the end of the process.

Comment 15

[Chris Peterson [:cpeterson]]

Christian says the redirect event does not remember the user-interaction flag.

needinfo'ing Agi because he said he would find the right owner or component for this bug.

Comment 16

[[ex-Mozilla] Agi Sferro | :agi]

It looks like we hard-code aHasUserGesture=false, so this is actually our bug: https://searchfox.org/mozilla-central/rev/b96000c5311dd5f2065ff7fc97d92bb8753dc3f4/netwerk/ipc/DocumentLoadListener.cpp#2589-2592

Comment 18

[Kirtikumar Anandrao Ramchandani]

Has this bug received any update on CVE or Reward after the patch? :)

Comment 19

[Roger Yang [:royang]]

Hi Chris, who do we talk to about this? I'm not sure if we ever fixed this as well.

Comment 20

[Chris Peterson [:cpeterson]]

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

Has this bug received any update on CVE or Reward after the patch? :)

I don't know. This bug has the sec-bounty? flag set, so the Firefox Security team is monitoring this bug.

Comment 21

[Kirtikumar Anandrao Ramchandani]

(In reply to Chris Peterson [:cpeterson] from comment #20)

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

Has this bug received any update on CVE or Reward after the patch? :)

I don't know. This bug has the sec-bounty? flag set, so the Firefox Security team is monitoring this bug.

The issue isn't patched yet. @Roger, can you take a look at this too? This isn't patched and I can reproduce on the latest build of Firefox. :)

If there's a relevant code-base just like the intent schema, do you mind sharing it? I am allowed to commit a patch?

Comment 22

[Chris Peterson [:cpeterson]]

If there's a relevant code-base just like the intent schema, do you mind sharing it? I am allowed to commit a patch?

This bug is in our backlog, but we welcome patches from contributors!

Here are instructions for building Firefox Android:

https://firefox-source-docs.mozilla.org/mobile/android/fenix.html

I don't know if this fix would be in the Firefox Android code (on GitHub: https://github.com/mozilla-mobile/firefox-android) or in GeckoView code (in the mozilla-central repo with Gecko code). We should also test whether Firefox Focus has this same bug.

Also, since this is a security bug, the patch should not use the public Phabricator review tool. You would want to attach a raw patch file to this private bug.

Comment 23

[Kirtikumar Anandrao Ramchandani]

To me, it looks like the case is of GeckoView, thanks for the information

Comment 24

[[:owlish] 🦉 PST]

Hi Segun, can your squad take a look at this one please?

Comment 25

[Segun Famisa [:segun]]

Hi :owlish,

Sure we can have a look at it. I tried accessing the test url in the description of the bug, but it's no longer available.

Do we have an example of a type of link (or an html sample) that still demonstrates this vulnerability?

Comment 26

[Segun Famisa [:segun]]

Hey Kirtikumar Anandrao Ramchandani

Could you please help with updated repro steps? A recording, and the type of html content that can help repro the bug will be also helpful.

I just want to be sure we have the latest picture of the bug since it's been a while and various related bugs have been looked at.

Thank you!

Comment 27

[Daniel Veditz [:dveditz] out until Nov 10]

There is a copy of the testcase in the attachments!

Comment 28

[Segun Famisa [:segun]]

Thanks :dveditz

We tried the the attached testcase, but on Fenix, the experience has diverged from what was originally reported:

Actual results:
It will click on behalf of the user and transfer the USSD code to the dialer

Expected results:

It should click on behalf of the user for this specific case.
To know this behavior, you can test this on Chrome and Edge Android, you will find that they will block it because this causes a no-click attack related to USSD.

Right now the actual experience on Fenix is:

Nothing happens when the link is clicked.

It does feel like the attack is no longer happening, but we should still at least show an intent chooser to the user.

Is this a correct evaluation? OR can you still reproduce the issue?

Comment 29

[Daniel Veditz [:dveditz] out until Nov 10]

This bug was a combination of bug 1728742 and bug 1810705: you could use the testcases in bug 1810705 to test it. Since it's the same reporter it will be clearer to make this one a dupe

Comment 30

[Kirtikumar Anandrao Ramchandani]

Hello,

Sorry for late response. This bug shall be treated separately I feel. Can we still separate the bug from 1810705?

The thing over here is, in browsers utils when there is any external protocol it should not be initiated without user’s gesture but in Firefox, it clicks on behalf of the user on chrome it behaved differently back then

For the comment 28, the result has diverged because the bug 1810705 is patched so it is asking for user gesture for switching to the next app but isn’t checking if there was user gesture to open dialer.

Comment 31

[Segun Famisa [:segun]]

Hey :dveditz

Could you please cc me on bug 1810705? I don't seem to have access. It would help us properly figure out what action needs to be taken regarding this bug, or if no action is needed at all.

Thanks.