1728742 - (CVE-2022-22758) Using `tel:` URI to perform USSD attack

Status: RESOLVED FIXED

(GeckoView :: General, defect)

Description

[Kirtikumar Anandrao Ramchandani]

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

Steps to reproduce:

1. Visit https://kirtikumarar.com/mozilla/ussd.html
2. Click on Hyperlink

Actual results:

It sends the complete USSD code to the dialer and shows the IMEI Number.

Expected results:

It should strip out everything after " * "

Comment 1

[Kirtikumar Anandrao Ramchandani]

Issue is tested on: Firefox browser 37.4.0 (Build #2015831131) and Firefox Nightly 93.0a1 (Build #2015831595)
Video PoC: This will be shared through mail as it will disclose device IMEI Number
Exploit Scenario: One can use different USSD codes to erase users' devices, turn on particular settings, turn off settings, etc.

How we're actually trying to make it work?
--> Browsers have the ability to strip out the complete USSD code after * for example if you will visit https://kirtikumarar.com/mozilla/fail.html and click the hyperlink and you can see the Firefox stripped out #06# after the asterisk. To bypass that functionality of stripping out, we are encoding the # --> %23. So, when you navigate to https://kirtikumarar.com/mozilla/ussd.html and click on the hyperlink, you will see that the complete USSD code was sent to the dialer and your device IMEI number was popped.

Previously, a similar case was found by me, Patrick Walker, and Eric Lawrence in Chrome but it was a case where we were sending the USSD code from desktop to device. Here, the Chrome security team applied a clever patch: https://chromium.googlesource.com/chromium/src/+/e041be8dc8b5b9e3012e752c2636fcf1cd8b0b1d

The issue in Chrome had priority of Low because were sending it from desktop to device and asking the user to click on send to device a function to perform the attack. Here, the issue is possible on the device itself. So, the severity has drastically increased due to fewer user interactions. A suggested patch here will be like the Chromium team applied in the Click-to-call i.e. we should strip out everything added after the asterisk for example %, # and * which will be the best solution to fix this case.

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Looks like Fenix regressed bug 794034. GVE and Fennec 68 has https://searchfox.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/IntentUtils.java#70 which prevents this from working. Fenix either needs to port it or have bug 1685152 fixed.

Comment 3

[Kirtikumar Anandrao Ramchandani]

Looks like Fenix regressed bug 794034.

Might be. But that's really a good patch where Chrome and Firefox are having the intended behavior of blocking tel: URIs in the iframe. The bug 794034 is like (https://bugs.chromium.org/p/chromium/issues/detail?id=746427). If you don't mind, can we add Eric Lawrence into this bug if I share his mail as he has collaborated with me on multiple URI-related bugs, and this first tel: URI vulnerability was found after his bug (https://bugs.chromium.org/p/chromium/issues/detail?id=746427#c15).

https://searchfox.org/mozilla-central/source/mobile/android/geckoview/src/main/java/org/mozilla/gecko/util/IntentUtils.java#70

The bug ID attached in it is a case of frame-src? If yes, Chrome and Firefox (Android) both are blocking tel: URIs in the frame with a message in console when we do USB Debugging.

bug 1685152

Seems to be clean. May I know if this case will be taken into consideration?

Comment 4

[Kirtikumar Anandrao Ramchandani]

Adding Eric Lawrence with whom I collaborated on tel: URI bugs, Microsoft folk as he has better idea than me.

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

As part of my previous comment I updated the testcase from 794034 to use <a href=""> at https://www.kevinbrosnan.net/testcases/794034-s3-own-factory-reset-v5.html. The code I pointed at still works for Geckoview Example. The Fenix rewrite definitely regressed this.

Comment 6

[Kirtikumar Anandrao Ramchandani]

It would be better if you don't use the Factory reset USSD code in the testcase, replace it with IMEI number or any. If any mere mortal like me clicks that link or any analyst, their device might get erased especially Android 7.0 and lower will surely get erased directly. I'll share PoC what happens when just clicking through Mail as I mentioned earlier. I'll make poc for IMEI and not factory data reset.

Comment 7

[Frederik Braun [:freddy]]

Unfortunately, Android Studio is failing me and I can't reproduce locally.
I'm currently rating this sec-moderate but might as well be sec-high, if it doesn't require any user interaction

Kevin, can you please weigh in on the security rating based on these questions?

• Does this require any user interaction?
• i.e., Does it open the dialer app or does it directly trigger the USSD code to be "executed"?
• if the iframe does not directly trigger it, would a JavaScript click() call on the link trigger it?

Comment 8

[Frederik Braun [:freddy]]

Forgot the needinfo flag. Question in comment 7.

Comment 9

[Kirtikumar Anandrao Ramchandani]

A few observations for (comment 7):

Does this require any user interaction?

Yes, one will need to click on a hyperlink or use another function that can make it User interaction-free.

i.e., Does it open the dialer app or does it directly trigger the USSD code to be "executed"?

This is actually different behavior in different devices. On many of the Samsung devices (latest ones), it is requiring user click whereas, on Lenovo devices and few other ones, it is directly getting executed especially when the devices are Android 7.0, it will directly trigger the USSD code and get executed on the dialer. Currently, I am finding the device which are having this behavior. I will share a PoC for the same through mail as it will disclose the IMEI Number.

if the iframe does not directly trigger it, would a JavaScript click() call on the link trigger it?

iframe in Firefox and Chrome both block the tel: URIs. So, it won't work here for us to decrease the user interaction.

Comment 10

[Kirtikumar Anandrao Ramchandani]

I've sent a video PoC of IMEI Device on [e-mail] where the USSD code directly gets rendered on the Dialer App. Can somebody please check?

Comment 11

[Kevin Brosnan [Ex-Mozilla]]

For almost all tel: uris it will place the number in the dialer and the user would need to press call button to initiate the call or action. The USSD code in some cases will auto run. Using the two main phones I have the Samsung dialer on a Note 9 will not accept USSD codes from other applications. On my Pixel 2 XL the code auto runs using the Google dialer.

My rating would be more in the sec-low range, as Google rated it in 1180510 It could be used in an annoying DoS. The data can't be exfiltrated without coercing the user to manually screenshot or painstakingly manually copy the numbers. You might be able to use it to lend credibility to a support scam.

Comment 12

[Kirtikumar Anandrao Ramchandani]

The USSD code in some cases will auto run.

In almost all cases, it will auto run especially when the is using any 3rd party dialer like Truecaller, the chances will increase. This isn't tested but an observation when tested on a device which had a 3rd party dialer which took any USSD code from other application and rendered it for the user--auto run.

Using the two main phones I have the Samsung dialer on a Note 9 will not accept USSD codes from other applications.

Correct. In Samsung devices, when a USSD code is sent to dialer from any 3rd party, it will clear it and won't render it for you, as far as I know. But remaining all the devices are affected also iOS but in iOS, you might have same feature as Chrome i.e. asking user showing a prompt with any message like: "Hey, do you want to calll this no.? " which stops the attach there.

My rating would be more in the sec-low range, as Google rated it in 1180510 It could be used in an annoying DoS. The data can't be exfiltrated without coercing the user to manually screenshot or painstakingly manually copy the numbers. You might be able to use it to lend credibility to a support scam.

sec-low isn't digestible here, imho. If you've gone through Chromium bug- 1180510, that issue has low severity due to the reason that:
The issue is a click-to-call where user open the link on desktop ans then clicks on it later clicks on "send to device" this has increased user interactions and that's why the severity is low in that case of Chrome. I don't know how the sec-low was counted by you, it was expected high because here, the vulnerability isn't like chrome that it is sent from desktop->device. Instead it is directly a 1-click from the Browser. But anyways, as the severity is counted low from your side and no, wouldn't prefer to keep this case private and we should make it issue public directly because the severity isn't counted in the manner it should be. The Chrome bug is completely different from this case.

1. Can you apply their click-to-call patch on this case?
2. Is this vulnerability like 1180510 that we are sending USSD code from desktop to device?

Making issue public would be more helpful because sec-low for this case is arguably not acceptable neither for me nor for any other researcher.

Comment 13

[Frederik Braun [:freddy]]

@Kirtikumar: Let's remember not to turn this conversation into a price & reward haggle and keep this focused on a correct understanding of the issue at hand.

Kevin, you said the code automatically ran on your Google Pixel 2 XL, which makes it look like an attacker can trigger it on some default configurations. In this case, an easy-to-trigger factory reset without user interaction could be rated as "sec-moderate", as it is a very annoying DoS.
Let's keep this rated at moderate.

Comment 14

[Kirtikumar Anandrao Ramchandani]

Let's remember not to turn this conversation into a price & reward haggle and keep this focused on a correct understanding of the issue at hand.

Sure. No issues. :)

Kevin, you said the code automatically ran on your Google Pixel 2 XL, which makes it look like an attacker can trigger it on some default configurations. In this case, an easy-to-trigger factory reset without user interaction could be rated as "sec-moderate", as it is a very annoying DoS.

Correct. And also, the issue doesn't uses extra user interactions like it does in Google Chrome bug as it was a Desktop->Device. "sec-moderate" is acceptable.

Thanks for clarification!

Comment 15

[Kevin Brosnan [Ex-Mozilla]]

As far as I know there is no factory reset case with Fenix. The Samsung dialer reset codes only work on devices that run Android 4.0.4 or lower (Samsung Galaxy S3 era and earlier). The Galaxy S3 running Android 4.4 can no longer be reset using USSD codes. I have personally verified this and https://gizmodo.com/security-bug-can-wipe-out-your-android-phone-by-visitin-5946334 is another source. Fenix requires Android 5+ so the S3 and earlier devices are unsupported (and protected in Fennec v16-68 due to the code I mentioned in comment 2). What has been demonstrated is a forced "popup" with the device's serial numbers.

Comment 16

[Kirtikumar Anandrao Ramchandani]

I've tested on Factory data reset on Android 7.0

Comment 17

[Kirtikumar Anandrao Ramchandani]

I am adding Annevk into this bug as he has worked on tel: URI bug. When looking at his comment:

When writing tests we should also test %23, %2A, and maybe even %2523 (in case there's some incorrect decoding happening along the way to the target).

His comment seems to be very useful as my bug uses %23 which is actually encoded. Mozilla was blocking * after this patch. We should block %23 as well as double encoded chars i.e. %2523,

Here, there is an interesting case at exploit, you can see that it sends *2523062523 which seems to be wrong when it sends decoded part from the encoding, it should have sent *#06# but somewhere it seems to be broken. When you will try *%2306%23, you can see it is successfully sending a complete USSD code: *#06#.

Might be we need patch when there is a double encoding too, yes?

We used a similar exploit in this bug. Refer to it. It is also a double encoding but that case was from desktop to device this is in the device itself. :)

Comment 18

[Anne (:annevk)]

I don't really have detailed knowledge of tel: URLs unfortunately.

It seems this is a duplicate of bug 797034?

Comment 19

[Kirtikumar Anandrao Ramchandani]

It doesn't seem to be duplicate to me. May I know how you're telling it duplicate, please? The bug 797034 doesn't talk about particularly blocking of %23. I've tried to explain two bugs in comment#17:

1. We should actually be stripping out chars after *.
2. When there's %2523, it seems like it strips out percentage but not the numbers. So, we should actually be stripping out everything after * which will be the robust solution here.

Comment 20

[Kevin Brosnan [Ex-Mozilla]]

It is not a duplicate. This is a Fenix only bug as I stated in comment 2. Gecko/Geckoview example browser do not send the URIs from comment 0 and 1 to the dialer. When we resolve this this we should evaluate if we should treat SMS/MMS in a similar manner.

Comment 21

[Kirtikumar Anandrao Ramchandani]

Friendly ping. :-)

We're working on the blog where we'll cover browsers that were found to be vulnerable from similar USSD cases with this URI.

1. Any patch introduced so far which we can use currently for analysis?
2. Any approximate date when we will be allowed to make the issue public?

Comment 22

[Kirtikumar Anandrao Ramchandani]

(In reply to Kevin Brosnan [:kbrosnan] from comment #5)

As part of my previous comment I updated the testcase from 794034 to use <a href=""> at https://www.kevinbrosnan.net/testcases/794034-s3-own-factory-reset-v5.html. The code I pointed at still works for Geckoview Example. The Fenix rewrite definitely regressed this.

In your test cases, it failing, not able to pass the USSD code to erase the device. Your test case is below one on the website:

<!DOCTYPE html>
<head>
    <title>S3 factory reset testcase</title>
</head>
</body>
    <frame src="tel:*2767*3855%23">
    <a href="tel:*2767*3855%23">Totally safe link</a>
</body>

I assume that the problem is from the USSD code after 2767. But you will be able to successfully encode the testcase which I was using:
https://kirtikumarar.com/mozilla/ussd.html

If you want a video POC, let me know. And we shouldn't be having Hyperlink as well as an iframe in the same test case like we didn't use them both in our chromium bug at the same time it was either hyperlink or iframe else it might be confusing and we won't be able to find which is actually failing or breaking on the midway.

If in case it keeps missing, we can double encode it and use it as I mentioned in comment 17:

Here, there is an interesting case at exploit, you can see that it sends *2523062523 which seems to be wrong when it sends decoded part from the encoding, it should have sent *#06# but somewhere it seems to be broken. When you will try *%2306%23, you can see it is successfully sending a complete USSD code: *#06#.

The exploit over there is https://kirtikumarar.com/mozilla/ussd2.html which uses double encoding. The better one will be the double encoding because it was vulnerable in 2 more browsers and both of them have patched- Chrome and Yandex ( Yandex separately as it was their lite browser).

Any possibility @Kevin sir, you got any idea why the chars aren't being decoded from the test case in comment 15? I don't see any problem in the complete test case of yours, it is created correctly from start till end.

Comment 23

[Kirtikumar Anandrao Ramchandani]

Note: When the iframe and hyperlink are bisected from @kevin's test case, it worked correctly on Android 9.0 (Tested OK). But when it was with frame, it got a problem. Btw, Mozilla is working as intended for the below test case in Android but we need a similar case on the desktop too:

<iframe src="tel:*2767*3855%23"></iframe>

You will see that the Mobile is blocking tel: URI in the iframe but the desktop doesn't. The Chrome is working on this case at here: https://bugs.chromium.org/p/chromium/issues/detail?id=1180510#c10

Relevant bug shared by Chromium team member for that iframe case: https://bugs.chromium.org/p/chromium/issues/detail?id=1011429

So far, the chrome team has disabled their click-to-call functionality from the desktop to stop this problem.

Comment 24

[Kirtikumar Anandrao Ramchandani]

A friendly ping if there's any update please share because if it is >=30days, I need to forward the vulnerability to GPSRP (Google Play Security Reward Program) as the case is affecting more than 100 Million users.

Comment 25

[Kirtikumar Anandrao Ramchandani]

(In reply to Frederik Braun [:freddy] (out of office) from comment #13)

@Kirtikumar: Let's remember not to turn this conversation into a price & reward haggle and keep this focused on a correct understanding of the issue at hand.

Kevin, you said the code automatically ran on your Google Pixel 2 XL, which makes it look like an attacker can trigger it on some default configurations. In this case, an easy-to-trigger factory reset without user interaction could be rated as "sec-moderate", as it is a very annoying DoS.
Let's keep this rated at moderate.

The reason why I was arguing about severity is due to the reason this is not just a remote DoS, here, Mozilla is allowing attackers to abuse government functions too. A small example is here: http://cashlessindia.gov.in/ussd_services.html

Previously, in India, the government has introduced cashless functionality where users can use UI, USSD, etc. ways to perform transactions. Here, an attacker can execute USSD code and perform transactions on behalf of the user. Obviously, a government won't handle such nefarious work of attackers, for example, the Indian government didn't handle the case of Whatsapp data privacy case. Here, Mozilla is freely allowing attackers to abuse the cashless function of the Indian government. If you still believe this is limited to a remote DoS, we can have an Indian government folk in this report and ask his permission to perform the "Banking USSD attack" on their users.

Note: I have successfully verified this case of USSD banking. The other case next which has to be verified is of transferring balance through USSD code of telecom companies. For example, if you execute one code in India, you can transfer Talktime to the receiver. If the SIM Card is postpaid the user is going to face a lot of problems. :(

CC'ing Daniel sir as he helped well in a few past analyses of Mozilla cases.

Comment 26

[Kirtikumar Anandrao Ramchandani]

Forgot to share here is a list of 38 Government as well as Private banks of India who can be abused by this USSD attack: http://cashlessindia.gov.in/ussd_services.html

Comment 27

[Kirtikumar Anandrao Ramchandani]

May I know what does: Whiteboard: [exploit published after Dec 23 2021] mean?

Comment 28

[Daniel Veditz [:dveditz]]

In comment 24 you said "if it is >=30days, I need to forward the vulnerability to GPSRP". Just making sure people know there's a deadline here.

Comment 29

[Kirtikumar Anandrao Ramchandani]

Oh, ok waiting for somebody to patch it.

Comment 30

[Kirtikumar Anandrao Ramchandani]

Hi Daniel sir,
3hrs are left for 23rd Dec (as per Indian Standard Time). May I know if any security folk has looked into this case or not? We haven't received the update from the team for 3months even though the issue can be used to abuse the government and users in the worst possible way. :-)
I hope you're looking into the bug.

Comment 31

[Kevin Brosnan [Ex-Mozilla]]

Amedyne and Christian are better options than Stefan due to PTO.

Comment 32

[Kevin Brosnan [Ex-Mozilla]]

Christian and I talked. We are looking at porting the Fennec patch to Fenix in the new year. Just about all the Fenix team are on PTO through Jan 3 (Europe/NA). Our understanding of the problem is as follows

• The Samsung device factory reset usecase is not applicable to Fenix. This was a problem on Galaxy S3 and earlier era phones running Android 4.x which we don't support. The unsupported Fennec v68 will run on affected devices has the patch I pointed to above.
• Modern Samsung devices using the Samsung dialer do not accept dialer codes from external apps.
• USSD code generally is a DoS, see comment 0 for an example. People in specific countries where USSD codes are used for additional features may be more severely affected if their dialer does not protect them (comment 25)
• Evaluate if SMS/MMS is in scope

Comment 33

[Christian Sadilek [:csadilek]]

We have a "backport" of the Fennec patch ready for A-C that also handles the double encoding case mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1728742#c22.

We would like feedback from the GeckoView team though, because GV already has most of the required logic in place as part of the IntentUtils.isUriSafeForScheme call, invoked for load requests [1]. However, this code path is not executed for load requests forwarded to the embedder [2].

Agi, what do you think? The advantage of handling this in GV is that the call to onLoadError would automatically display a meaningful error message to the user without any special handling in A-C/Fenix. We're happy to land the change in A-C/Fenix as well as a fallback.

[1] https://searchfox.org/mozilla-central/rev/996a2cafe472e9934b8cb91db63050f96d8a59cb/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoSession.java#499
[2] https://searchfox.org/mozilla-central/rev/996a2cafe472e9934b8cb91db63050f96d8a59cb/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoSession.java#1113

Comment 34

[Roger Yang [:royang]]

Attachment: tel_sms_intent_check.patch

Comment 35

[Kirtikumar Anandrao Ramchandani]

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

The team is patching Bug 1728742 as well as Bug 1741817 together, yes? Because Bug 1728742 can be used with no user interaction by taking Bug 1741817 the chain. So, both of the issues are going to be stripped out together? From what I see in the patch attached in Comment 34 by Roger Yang is to restrict the use of USSD codes *, #, and %.

Comment 36

[Christian Sadilek [:csadilek]]

The team is patching Bug 1728742 as well as Bug 1741817 together, yes?

Thanks for the pointer to the other ticket. The two tickets need separate patches. The patch attached and discussed here covers USSD codes and has higher priority given its security rating (see also https://bugzilla.mozilla.org/show_bug.cgi?id=1741817#c4). Bug 1741817 has different implementation aspects that still need to be discussed independently of this patch here.

Comment 37

[Roger Yang [:royang]]

Attachment: tel_sms_intent_check_2.patch

Comment 38

[Christian Sadilek [:csadilek]]

Comment on attachment 9257702 [details] [diff] [review]
tel_sms_intent_check_2.patch

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

r+ good to have as a fallback either way, but let's clarify https://bugzilla.mozilla.org/show_bug.cgi?id=1728742#c33.

Comment 39

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

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

We have a "backport" of the Fennec patch ready for A-C that also handles the double encoding case mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=1728742#c22.

We would like feedback from the GeckoView team though, because GV already has most of the required logic in place as part of the IntentUtils.isUriSafeForScheme call, invoked for load requests [1]. However, this code path is not executed for load requests forwarded to the embedder [2].

Agi, what do you think? The advantage of handling this in GV is that the call to onLoadError would automatically display a meaningful error message to the user without any special handling in A-C/Fenix. We're happy to land the change in A-C/Fenix as well as a fallback.

[1] https://searchfox.org/mozilla-central/rev/996a2cafe472e9934b8cb91db63050f96d8a59cb/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoSession.java#499
[2] https://searchfox.org/mozilla-central/rev/996a2cafe472e9934b8cb91db63050f96d8a59cb/mobile/android/geckoview/src/main/java/org/mozilla/geckoview/GeckoSession.java#1113

Yeah I agree this should be fixed in GV. It looks like we missed checking for uriSafeForScheme in code path [2].

Comment 40

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

Attachment: Bug 1728742 - Reject invalid schemes in onLoadRequest.

Comment 41

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

Attachment: Bug 1728742 - Add test for invalid schemes in onLoadRequest.

Comment 42

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

Comment on attachment 9258529 [details]
Bug 1728742 - Reject invalid schemes in onLoadRequest.

Security Approval Request

• How easily could an exploit be constructed based on the patch?: Not that easy, the patch adds a generic security check not related to tel: URLs specifically. Tests will land separately at a later date.
• Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?: No
• Which older supported branches are affected by this flaw?: all
• If not all supported branches, which bug introduced the flaw?: Bug 1619798
• Do you have backports for the affected branches?: Yes
• If not, how different, hard to create, and risky will they be?: The patches are all identical
• How likely is this patch to cause regressions; how much testing does it need?: The patch could potentially break loading URLs of various types however:

1. we have a lot of automated regression tests around this area
2. this code was accidentally removed in 77 but has been there for a long time

Comment 43

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

Set release status flags based on info from the regressing bug 1619798

Comment 44

[Tom Ritter [:tjr]]

Comment on attachment 9257702 [details] [diff] [review]
tel_sms_intent_check_2.patch

Approved to land and request uplift

Comment 45

[Tom Ritter [:tjr]]

Comment on attachment 9258529 [details]
Bug 1728742 - Reject invalid schemes in onLoadRequest.

Approved to land and request uplift

Comment 46

[Tom Ritter [:tjr]]

Comment on attachment 9258530 [details]
Bug 1728742 - Add test for invalid schemes in onLoadRequest.

Clearning sec-approval for the test. This can land after March 8th (assuming we uplift this to 97.

Comment 47

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Reject invalid schemes in onLoadRequest. r=jonalmeida
https://hg.mozilla.org/integration/autoland/rev/f67e35bd834013929d2579a6117656e18b14dd6d
https://hg.mozilla.org/mozilla-central/rev/f67e35bd8340

Comment 48

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta approval when you get a chance.

Comment 49

[Roger Yang [:royang]]

I'm assuming this is for Agi. Thanks

Comment 50

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

Comment on attachment 9258529 [details]
Bug 1728742 - Reject invalid schemes in onLoadRequest.

Beta/Release Uplift Approval Request

• User impact if declined: Some potentially insecure URLs might be allowed to load causing data leaks
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): Code is in the critical page load path but has been in production until 77 when the bug landed
• String changes made/needed:

Comment 51

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9258529 [details]
Bug 1728742 - Reject invalid schemes in onLoadRequest.

Approved for Fenix/Focus 97.0.0-beta.3.

Comment 52

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/4495f8356947

Comment 53

[Daniel Veditz [:dveditz]]

I think Freddy was right the first time on the rating. On our side it's a fairly minor regression, assuming phones are doing what they should have done all along, and should have learned from the Samsung disaster a decade ago. Sending "#" codes to phones that don't auto-dial is still a spoofing risk for users so we did want to treat this as a problem on the Fenix side.

Comment 54

[Kirtikumar Anandrao Ramchandani]

It's irritating behavior when reporter needs to explain the issue/severity again and again. Did you really visit crbug.com/1180510?
If yes, you should have noticed that the bug is actually click-to-call first the user open exploit in computer then sends to device and then opens it. Due to this reason the issue in the Chrome was counted low. Here, we aren't have computer neither we're asking user to do a click we're just asking user to follow a link and in browser exploitation we can "at least" have user to follow an HTML Page, yes? When are we making this issue public? Cheers!

Comment 55

[Kirtikumar Anandrao Ramchandani]

It's irritating behavior when reporter needs to explain the issue/severity again and again. Did you really visit crbug.com/1180510?
If yes, you should have noticed that the bug is actually click-to-call first the user open exploit in computer then sends to device and then opens it. Due to this reason the issue in the Chrome was counted low. Here, we aren't having computer neither we're asking user to do a click we're just asking user to follow a link and in browser exploitation we can "at least" have user to follow an HTML Page, yes? When are we making this issue public? Cheers!

Comment 56

[Frederik Braun [:freddy]]

I understand this is frustrating. We have indeed visited and read through the chrome bug extensively when we made the decision and we also need to factor two things in (Dan mentioned it already in comment 53):

1. The attack is almost 10 years old (https://twitter.com/pof/status/250540790491787264) and the issue was widely fixed in many Dialer apps, by making tel: URLs not auto-dial, but open with a pre-filled number
2. Given this prior history, we believe the attack relies on a secondary vulnerability in the phone's dialer app.

Even with us fixing this vulnerability, some other browser, some other app might end up triggering the same dialer bug. The situation is simply not resolved by patching and fixing all sorts of applications on the phone. The dialer needs fixing.

Comment 57

[Kirtikumar Anandrao Ramchandani]

Comment#56: Acknowledged! :)

Even with us fixing this vulnerability, some other browser, some other app might end up triggering the same dialer bug. The situation is simply not resolved by patching and fixing all sorts of applications on the phone. The dialer needs fixing.

Might be but famous browsers like Chrome, Firefox, etc aren't supporting this at the moment. Is the patch available in the Firefox Nightly channel now?

May I know what do they mean by the stuff which is updated in the WhiteBoard? Exploit isn't published yet. We'll publish it after the patch reaches Firefox and it passes 3weeks or so by that time, hoping that all the users might have received an update and we aren't going to get any users into a problem.

Thank you. It was great working with you all! :)

Cheers!

Comment 58

[Frederik Braun [:freddy]]

Looking from the commit linked in 52, it should be possible to verify this in Firefox for Android (Nightly and Beta).
Regarding the whiteboard tag: We thought you intended to publish the exploit but maybe we misunderstood comment 24.

Comment 59

[Kirtikumar Anandrao Ramchandani]

Issue is patched in the Firefox Nightly build. Nice patch by the way. :)

Comment 60

[Tom Ritter [:tjr]]

Attachment: advisory.txt