1929584 - (CVE-2025-0244) Android Firefox address bar spoofing through invalid protocols

Status: RESOLVED FIXED

(Firefox for Android :: Browser Engine, defect)

Description

[Umar Farooq [:Puf]]

Attachment: PufIndex.html

In Android Firefox there is possibilities to Spoof using 🌐 Google.com:// 🌐 apple.com://
When a user Click on link🔗 on page📄 it will replace the address bar to Google.com:// apple.com:// and changes the entire screen with attacker-controlled content.

the spoofed URL address appear to be very similar to the original attackers this type of altered URLs to trick users into thinking they are on a legitimate website which allows an attacker to spoof the entire screen with attacker-controlled content.

Steps to Reproduce:

1. Open PufIndex.html
2. Click on Open Google Login link🔗

Result: Successfully Spoofed URL address to Google.com://Login

I have attached video Link 🌐🔗🔒 reproducing the attack. ✅

OS Info 📱:
Firefox Version: [134.0a1]
Operating System: [ Android 14 📱 ]

Thank you

Comment 1

[Umar Farooq [:Puf]]

(https://youtube.com/shorts/mB4lwIkJofw) = attached Unlisted video Link 🌐🔗🔒 reproducing the attack. ✅

Comment 2

[Umar Farooq [:Puf]]

Just Adding a Colon : to any domain name it works 🌐 Google.com: 🌐apple.com:

Comment 3

[Umar Farooq [:Puf]]

Attachment: PufIndex.html

Comment 4

[Umar Farooq [:Puf]]

For your information, This Vulnerability effect only on Latest Firefox Nightly Version: [134.0a1] (Build #20160541750)

Comment 5

[Daniel Veditz [:dveditz]]

This sounds very similar to the bugs where you could spoof with a broken port: we were displaying the chosen URL first before we loaded it and it never loaded. In that case the server never responded (or eventually timed out). In this case we've gone out to ask the OS if there's support for that protocol and failed, but not clearing the URL bar or reverting to the original page.

On desktop we print the error to the console and simply don't navigate. I have no idea if the error here is the front-end doing the wrong thing or if that error never even makes it out of geckoview to the front-end.

Presumably you could make the lock icon look right if the attack was hosted on an https site (have not tried the attachment yet).

Comment 6

[Daniel Veditz [:dveditz]]

Not only does it show a lock, if you click the lock it says my connection is secure to "google.com:". How are we populating that dialog? Are we just parsing the URL and figuring that if we could load it that's what it must be? We should be getting that data from the SecurityInfo on the load, and clearly that's not making it out to the front-end

Comment 7

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:boek, could you have a look please?

For more information, please visit BugBot documentation.

Comment 8

[Umar Farooq [:Puf]]

looks like this vulnerability is fixed! in Due to latest update in Firefox Nightly 134.0a1

Please kindly Verify and Change Status to fixed

Comment 9

[Umar Farooq [:Puf]]

looks like this vulnerability is fixed, Due to latest update in Firefox Nightly 134.0a1

Please kindly Verify and Change Status to fixed, Thanks

Comment 10

[Umar Farooq [:Puf]]

I Have also Verified this one too in Latest version Firefox

the invalid "google.com:" protocol does not show in URL bar
can you please check on your side

Thank you

Comment 11

[Daniel Veditz [:dveditz]]

Can confirm this is fixed: I could reproduce the bug in 133.0b9 but not in 134.0b1 after I updated (and couldn't reproduce in a 134 nightly). I didn't see any "fixed in 134" Fenix bugs that could account for it.

Comment 12

[Daniel Veditz [:dveditz]]

Bug 1921426 fixed a core Gecko bug with external protocol handlers, but that would only change the behavior for things loaded by a web extension. That can't be the thing that fixed it.

There are also a whole lot of "[toolbar redesign]" bugs that were fixed but those don't look like the fix either. 1) the new design isn't enabled in 134 where this appears fixed, and 2) most of the changes were to the appearance and functionality of buttons and things in the toolbar but not really the functioning of how we update the URL-containing box.

I guess we'll have to do nightly build bisection to narrow this down
https://archive.mozilla.org/pub/fenix/nightly/2024/11/

Comment 13

[Daniel Veditz [:dveditz]]

Polly: do you know of what changes might have fixed this? Was it toolbar redesign work? It doesn't seem to be have been fixed as an intentional security fix in some related bug, at least as far as I can see.

Please pass the request on to a better person on the Android team if you weren't part of that work.

Comment 14

[Umar Farooq [:Puf]]

Looks like it is fixed in external protocol section

<a href="mailto:[e-mail]">Click email </a>

external protocol execution is not working in hyperlinks

Comment 16

[Polly [:polly]]

i am not aware of anything that has changed in this area from the android side, and can't see anything obvious from looking at the code.
Maybe [:zmckenney] knows of something that has changed in the toolbar that might have fixed this?

Comment 17

[Zac McKenney [:zmckenney]]

I'm not aware of any work for the redesign that would have affected this and I went back through all of the tickets since October related to the project and didn't see any that could be relevant. I can't be sure this is a Gecko/GeckoView issue but it seems to me like it would be.

Comment 18

[Frederik Braun [:freddy]]

Attachment: advisory.txt