Open Bug 1507582 Opened 3 years ago Updated 3 months ago

IDN spoofing: should use unicode confusables list to check any IDN domain against alexa top 10000 like chromium

Categories

(Firefox :: Address Bar, defect, P3)

defect
Points:
8

Tracking

()

People

(Reporter: avkovaleff, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: parity-chrome, sec-want, Whiteboard: [reporter-external] [client-bounty-form] [verif?])

Attachments

(1 file)

Attached image 2018-11-15_22-22-20.png
Hello, seems that there is bypass of idn spoofing protection in FireFox browser. 
There is an URL: http://airfrạnce.com. You can see how it's shown on my browser in attach.
But it should be: http://xn--airfrnce-rx0d.com/
It's actual for FF 63.0.1.
Flags: sec-bounty?
And still http://xn--airfrnce-rx0d.fr/ has the same effect.
Other browsers seem to not use punycode here either. I'm a bit confused because per the summary, this should have been addressed by bug 1366444 (duped to bug 1370497 which is marked fixed). Jonathan, can you take a look?
Component: Security → Address Bar
Flags: needinfo?(jfkthame)
Summary: Security: IDN check bypass → IDN spoofing:
Summary: IDN spoofing: → IDN spoofing: LATIN SMALL LETTER A WITH DOT BELOW
Bug 1370497 was about checking for combining marks that aren't expected to appear in the current script (like an Arabic vowel mark on a Latin letter). Here, the dot-below is a perfectly legitimate diacritic for a Latin letter 'a'; indeed, LATIN SMALL LETTER A WITH DOT BELOW is available as a precomposed character (U+1EA1), so this doesn't even involve a combining mark.

No different than a "spoof" like mózilla.org or appƚe.com or miçrosoft.com, really. I don't think this should be considered a bug.
Flags: needinfo?(jfkthame)
(Huh, apparently appƚe.com does get turned into punycode; the barred-L must not actually be permitted.)
http://xn--airfrnce-rx0d.fr/  - is in the Alexa TOp10k - so Chromium protects this domains and landed fix to the iOS 70 Beta and  in Canary 71. So it's strange, that Firefox doesn't protect such domains.
appƚe.com is currently converted to punycode in FF.
Duplicate of this bug: 1507617
Cf. https://bugs.chromium.org/p/chromium/issues/detail?id=703750#c45 .

I don't have a strong opinion on this - "protecting" the top 1000 domains is 'better' than nothing, but also arbitrary. Must suck to be the alexa top 10001 domain! ( https://chromium.googlesource.com/chromium/src/+/master/components/url_formatter/top_domains/README )

It'd be relatively straightforward to follow suit, but I'm not convinced it's worth doing.
Group: firefox-core-security
Status: UNCONFIRMED → NEW
Ever confirmed: true
See Also: → 1376641
Summary: IDN spoofing: LATIN SMALL LETTER A WITH DOT BELOW → IDN spoofing: should use unicode confusables list to check any IDN domain against alexa top 1000 like chromium
Keywords: parity-chrome
It seems wrong to me that certain domain names should get privileged treatment just because (at a certain moment in time) they happen to be higher-traffic than others. The Web ought to be a level playing field for all, not giving incumbents a favored position.
That said, I'm not necessarily against some form of "protection" to help users spot spoofing attempts. But I think it should rely on some well-defined principles based on Unicode character and script properties, and not on arbitrary lists that essentially say "these domains are more important than others".
Also, please, take a look to the Chromium IDN spoofing protection algorithm: https://www.chromium.org/developers/design-documents/idn-in-google-chrome. They check not TOP 1000 but TOP 10000 domains, because they are more attractive targets for massive phishing attacks. I think, that Firefox should do something similar.
Found several nice cases: 

http://xn--cloud-m4a.com   - icloud.com
http://xn--80aa0cn49azm.com - paypal.com
http://xn--twtter-q9a.com  - twitter.com
http://xn--fcebook-xqc.com - facebook.ru
http://xn--inopois-chbh.ru - kinopoisk.ru

Chromium canary deals with them successfully, Firefox doesn't.
Seems, that this ticked shouldn't be public?
(In reply to Andrey from comment #13)
> Seems, that this ticked shouldn't be public?

I don't see why not - all the information in the ticket is publicly accessible, bug 1376641 and bug 1332714 are both public. It's well-known Firefox hasn't taken the same approach to IDN as Chrome. In any case, I'll get a second opinion.
Flags: needinfo?(dveditz)
That's just my opinion =) Maybe I'm wrong. But I think that the ticket shouldn't be public because of several specific examples for important and popular sites. Despite the fact, that Firefox doesn't have Chromium approach, Firefox still has protection for some cases. If this issue is accepted as new and will be fixed somehow, it should be public after the fix.
We don't need to hide this issue. The Chromium algorithm is published and it's easy to test that we don't do that. As well this appears to be known to miscreants already since the domain from comment 0 (http://airfrạnce.com) was apparently misused and got itself blocked by the SafeBrowsing list.
Flags: needinfo?(dveditz)
Ok, thanks for the information. 

Will any CVE and/or bounty applicable to the report?
(In reply to Jonathan Kew (:jfkthame) from comment #9)
> It seems wrong to me that certain domain names should get privileged
> treatment just because (at a certain moment in time) they happen to be
> higher-traffic than others. The Web ought to be a level playing field for
> all, not giving incumbents a favored position.

It is unfair, but falling short of perfect IDN spoof detection such a list would protect the most users on the sites that are most likely to get phished against. Phishing is a numbers game, and unless the phishers target specific users ("spear phishing") there's not much return on creating spoofs for sites that only get a small number of visitors and then spamming that out widely in the hopes you'll reach those folks.

As long as the list is updated over time we would not ourselves be contributing to winners and losers, just following the public.

I'm not making judgements on whether we should do this or not. I'm not sure it's worth the effort since we're not seeing many attacks using this -- in fact there's plenty of evidence people are falling for phish on domains that look nothing at all like the domain they're supposed to -- but it's not a wrong thing to do IMHO.

(In reply to Andrey from comment #17)
> Will any CVE and/or bounty applicable to the report?

No, I'm sorry. This does not qualify for a bounty, and does not meet MITRE's criteria for a vulnerability to get a CVE.
Flags: sec-bounty? → sec-bounty-
Priority: -- → P3
Summary: IDN spoofing: should use unicode confusables list to check any IDN domain against alexa top 1000 like chromium → IDN spoofing: should use unicode confusables list to check any IDN domain against alexa top 10000 like chromium
Here is a case were Chrome and Edge show Punycode and Firefox does not:

https://www.аррӏе.com/

From Xudong Zheng's blog post:

https://www.xudongz.com/blog/2017/idn-phishing/
Duplicate of this bug: 1512133
Duplicate of this bug: 1597332
Duplicate of this bug: 1623648
Keywords: sec-want
Duplicate of this bug: 1636840
Duplicate of this bug: 1637901
Duplicate of this bug: 1645958
Duplicate of this bug: 1592055
Blocks: 1332714
See Also: → 1654230
Duplicate of this bug: 1654230
Points: --- → 8
See Also: → 1473911
Duplicate of this bug: 1678905
See Also: → 1656735
Duplicate of this bug: 1689895
See Also: → 1691472
Duplicate of this bug: 1694074
Duplicate of this bug: 1705888
See Also: → 1714565
See Also: → 1405963
Duplicate of this bug: 1721870
You need to log in before you can comment on or make changes to this bug.