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

Status: NEW

(Firefox :: Address Bar, defect, P3)

Description

[Andrey]

Attachment: 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.

Comment 1

[Andrey]

And still http://xn--airfrnce-rx0d.fr/ has the same effect.

Comment 2

[:Gijs (he/him)]

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?

Comment 3

[Jonathan Kew [:jfkthame]]

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.

Comment 4

[Jonathan Kew [:jfkthame]]

(Huh, apparently appƚe.com does get turned into punycode; the barred-L must not actually be permitted.)

Comment 5

[Andrey]

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.

Comment 6

[Andrey]

appƚe.com is currently converted to punycode in FF.

Comment 8

[:Gijs (he/him)]

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.

Comment 9

[Jonathan Kew [:jfkthame]]

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.

Comment 10

[Jonathan Kew [:jfkthame]]

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".

Comment 11

[Andrey]

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.

Comment 12

[Andrey]

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.

Comment 13

[Andrey]

Seems, that this ticked shouldn't be public?

Comment 14

[:Gijs (he/him)]

(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.

Comment 15

[Andrey]

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.

Comment 16

[Daniel Veditz [:dveditz]]

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.

Comment 17

[Andrey]

Ok, thanks for the information. 

Will any CVE and/or bounty applicable to the report?

Comment 18

[Daniel Veditz [:dveditz]]

(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.

Comment 19

[Chris Peterson [:cpeterson]]

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/

Comment 34

[Michael]

I have a really good suggestion for a partial solution.

In the address bar, the characters that can be used to spoof / confuse a user, should be displayed with a distinct font / color.
E.g. any character > ASCII 127 gets this display style (or a hand picked set of characters).

So for example, https://google.com/ would look normal in the address bar, whereas https://góogle.com/ would display the ó character e.g. in a bold italic font, and with a significantly different color than the default color, maybe even a font size difference. This would make it very easy for a user to see that something is amiss.

It'll take just a few minutes to implement.

The idea of checking for the top 10,000 sites on alexa is terrible. It means all the sites on the Internet, except the top 10,000, are deemed not to be important, and are easily spoofed. A site with 100 users can also be an important site.

Comment 35

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

The severity field for this bug is relatively low, S3. However, the bug has 14 duplicates and 10 See Also bugs.
:adw, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 36

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Comment 38

[Valentin Gosu [:valentin] (he/him) {{ AFK in July }}]

If we're going to implement something similar, here's the chromium code for reference:
https://github.com/chromium/chromium/tree/ce69d5ad5bbbb8c9ae35500c68a7920740b4241a/components/url_formatter/spoof_checks/top_domains

Comment 39

[Sean Kim [:sekim]]

This bug should handle Latin lookalikes that Bug 1885096 did not address.