1419275 - (CVE-2025-23109) Address bar spoofing on iOS using long hostnames

Status: RESOLVED FIXED

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

Description

[Khalil Zhani]

Attachment: Screen shot

Today I have discovered a vulnerability similar to address bar spoofing where an attacker can send a fabricated link to a victim and if he (victim) opens that link in his iOS Firefox browser his url on the address bar will be spoofed.

I expected Firefox will show The URL will show ....loginsgn.google.com.pk.bntk.pl as in Firefox Android.

instead of showing:
    |[lock]https://loginsgn.google.com.pk...|

show:
    |[lock]loginsgn.google.com.pk.bntk.pl|

PoC: 

http://tinyurl.com/ycalmsax

Comment 1

[Khalil Zhani]

See also: https://bugs.chromium.org/p/chromium/issues/detail?id=181623

Comment 2

[Khalil Zhani]

Version 10.2 (7796) iOS.

Comment 3

[Khalil Zhani]

Any update here?

Comment 4

[Khalil Zhani]

Also visit: https://long-extended-subdomain-name-containing-many-letters-and-dashes.badssl.com/ysigsgksgkskgslgsogslgslgslgslgslgsogsogsogslgsogsyosoys

Result:
The URL bar does not show 'badssl.com'

Comment 5

[Khalil Zhani]

Is this a valid bug? any update on this bug?

Comment 6

[:Gijs (he/him)]

Ni for comment #5...

Comment 7

[:garvan]

Firefox Android ensures to always focus the ETLD+1, and fades out the left and right rather than using ellipses.
Ellipses can clash with the truncation of a URL (for example, if truncated at a dot, adding three dots next to it would look very odd) so fading the truncation is a smart approach. Also, truncation is required at beginning and end, and double ellipses would look odd.
Filing a Trello request for UX to review this.

Comment 8

[lmarceau]

This is more of a feature request, we should align with Android on how we show the URL.

Comment 9

[lmarceau]

Android ticket is: https://bugzilla.mozilla.org/show_bug.cgi?id=1656735

Comment 12

[mreagan]

Based on what I can see in this ticket, we should be able to resolve this as fixed with the new iOS toolbar redesign which AFAIK is slated to roll out in v133. If anyone believes that's not correct please LMK.

The related Jira for this ticket is still in QA Needed status however so I will wait until it's validated to mark as Resolved.

Comment 13

[Andrei Bodea[:andrei]]

Verified as fixed on v133 (46984) with iPhone 15 Pro (18.2) with the new iOS Toolbar experiment.
With the new iOS Toolbar -> it is correctly displayed and the badssl.com is displayed in the URL.

But without the new iOS Toolbar -> the badssl.com is not displayed.
Matt if you consider the above ones are enough we can close this and the Jira ticket.

Comment 14

[mreagan]

Based on the info I've seen so far, the plan on iOS is to eventually move to the new toolbar design for all users. So as long as this is addressed with the experiment enabled I think we can safely close. My only concern is that this will be published as fixed for whatever version the Bugzilla is tagged in (currently v133), which means if we're running any type of A/B experiment or phased rollout where some users still have the old toolbar, the security issue is still present.

@dveditz Do you know offhand how we typically handle fixes that are part of incremental rollouts? I am double-checking the plan on iOS but wanted to make sure the ticket was flagged correctly and we didn't publish the advisory too early.

Comment 15

[Daniel Veditz [:dveditz]]

Usually we don't publish it as "fixed" until it is fixed for everyone, that is, after the roll-out is complete. There's a subset of users who turn off experiments (at least on Desktop... don't know what the iOS population is like).

Comment 16

[Daniel Veditz [:dveditz]]

Are there bugzilla bugs for the new toolbar, or at least the experiment? If so they should be added to the "Depends on" field.

I think I've found the relevant Jira tickets and added them to the "see also". Please correct these if wrong.

• FXIOS-8038 is the Toolbar Redesign epic
• FXIOS-8728 appears to be this bug specifically ("Display effective TLD in url text field")
• the patch itself was in https://github.com/mozilla-mobile/firefox-ios/pull/19733

According to FXIOS-8038, v133 is only a "Beta experiment" it's not right to consider that version anyway. v134 is starting with a 20% roll-out, with v135 being the full target version. "135" isn't an option yet so I moved it to 134; not really right either, but more accurate than blank?

Often for desktop projects like this we have a separate "turn it on in release by default" task bug, but I didn't see anything like that. Does the iOS team use the status of the Epic itself for that? If you do have something like that then it would be useful to link it here, also.

Comment 17

[mreagan]

I might have incomplete information but my understanding was that the new toolbar experiment is rolling out in v133. I think either Andy or Winnie would be best to confirm that though.

@nfurlan: can you possibly confirm how the experiment rollout for the new toolbar will proceed?

Comment 18

[mreagan]

Given that we're currently rolling out the new toolbar experiment I'm going to mark as Resolved for the tagged fix version. I haven't been able to get full clarity around the rollout phases but I believe we're far enough now to consider this as a fixed.

Comment 19

[mreagan]

Attachment: advisory.txt

Comment 20

[Daniel Veditz [:dveditz]]

Given how long it's taking to role out the new toolbar experience, in hindsight we should not have released an advisory for this until the fix was fully rolled out. An advisory says "if you upgrade to this version you will be safe from this bug", but that's not true with a partial roll-out like this. We should consider a roll-out like this as a kind of "extended beta".

Not quite sure how we'd track that so we don't forget to issue the advisory when it does finally get out to everyone. keep bumping the fxios tracking version one release ahead at a time, and ask about the roll-out status when we get to release time? In the Desktop and Android products we would make a bug like this "depend on" a tracking bug like "enable XXX for release" or "roll-out XXX to 100%", and then when those are are finally fixed that would trigger checking the bugs that depend on it. But the fxios team tracks most of their bugs elsewhere so that may not work as well.

Comment 22

[Khalil Zhani]

Doesn't this qualify for a bounty? Thanks.

Comment 23

[Daniel Veditz [:dveditz]]

There had not been a request for one until now. If you are interested in the bounty please use the form linked to from our bug bounty page, or follow the mailing instructions for ones that were filed without the form.