1473911 - IDN spoofing with combining marks (especially i,j,l)

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect, P3)

Description

[50189695]

Attachment: ix.png

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

Steps to reproduce:

Would you like to check the characters listed in https://gist.github.com/o11c/b457cde4ea22bae9b36a4bde6f0ef23b , during my simple test, firefox accepts a lot of characters in this list, such as i̓ j̓ i̇ j̇ k̇ and show them directly in the address bar. This could lead to a homograph attack. 

Some domains allows user to register such domains, such as register.to, for I have just registered a domain xn--baidu-9fd.to, it shows in the address bar, and is almost identical to baidu.to, the same thing happens to www.a̦mazon.to (www.xn--amazon-w4d.to) ,etc.

https://www.whois.com/whois/bai%CC%87du.to
**********************************************************
This DNS Propagation Check returned a small amount of
results. If a particular result was expected, please
confirm the domain name and record type for this check
and try again for greater accuracy.
**********************************************************


Request:
----------------
Domain Name: xn--baidu-9fd.to
DNS Record Type: A
----------------

Result:
----------------
92.242.144.10
----------------

First 15 Randomly Chosen Global DNS Servers To Respond:
----------------------------------------------------------------
1 | 156.154.70.22 | ULTRADNS - NeuStar, Inc. | US

Total Randomly Chosen Global DNS Servers That Responded With This Same Result: 1
Total Processing Time: 22.13 seconds


**********************************************************
This DNS Propagation Check returned a small amount of
results. If a particular result was expected, please
confirm the domain name and record type for this check
and try again for greater accuracy.
**********************************************************


Actual results:

The URL of xn--baidu-9fd.to looks almost identical to baidu.to, I am using the "CombiningDotAbove" to combine a dot above letter i.



Expected results:

The URL should be shown in xn-- form in the address bar, as the Chrome does.

Comment 1

[50189695]

I have updated the DNS settings, you may try these two domains now,
http://xn--baidu-9fd.to/  resolves to 158.85.81.9
http://xn--google-w7d.to/  resolves to 127.0.0.1

Comment 2

[Daniel Veditz [:dveditz]]

> homograph attack

That's not the right term. That refers to identical-looking glyphs from different script families ("homo-" meaning "same"), for example confusing latin and cyrillic characters. This is spoofing through visual similarity, taking advantage of the brain's tendency to filter out "unimportant" details to keep us sane. It's a refined version of the "paypa1" spoof which doesn't even require IDN.

I know Chrome is stricter than we are about combining marks with i,j, and l, but even if we followed suit that doesn't solve your http://g̵oogle.to/ example (which Chrome also accepts).

I think we already have a bug on the generic combining characters problem. We had a bug on the i/dotless-i thing but resolved it less aggressively than Chrome. Is it worth revisiting that? (Chrome's bug is https://bugs.chromium.org/p/chromium/issues/detail?id=774842)

Not sure if there's many good options for the combining mark issue.

a) disallow combining marks with Latin: if the hundreds of pre-composed characters aren't right then you get punycode. Of course some of the precomposed combinations could spoof the unwary.

b) Convert labels to their ASCII skeleton, and then see if the user has that domain in their history. If it is and the IDN forms don't match then they get punycode. Some people might get fooled but if it's not in their history but at least they probably don't have a login for that site that can get phished. Doesn't protect people who clear their history at shutdown, though that's not the default behavior. Also might slow down pageload.

c) ???

I guess that all belongs in the generic bug. Is there something specific we want to do about i,j,k,l to match chrome?

Comment 3

[Jonathan Kew [:jfkthame]]

There was also some discussion of this in bug 1405845.

Personally, I think Chrome's special-casing of a few combinations was a bit arbitrary, but option (a) above is a reasonable mitigation that we could do (question: besides Latin, should it be extended to Cyrillic and Greek?). If there's an appropriate forum for discussion/coordination with other browsers, that also seems worthwhile.

Not sure who "owns" this and can drive it forward at this point?

Comment 4

[:Gijs (he/him)]

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> Personally, I think Chrome's special-casing of a few combinations was a bit
> arbitrary, but option (a) above is a reasonable mitigation that we could do
> (question: besides Latin, should it be extended to Cyrillic and Greek?). If
> there's an appropriate forum for discussion/coordination with other
> browsers, that also seems worthwhile.
> 
> Not sure who "owns" this and can drive it forward at this point?

AFAICT the decisions about what gets punycode and what doesn't are effectively made by networking code (ie our IDN implementation), so let's move it there and they can prioritize it?

Comment 5

[Daniel Veditz [:dveditz]]

The "spoofing" aspect of this is primarily a front-end display issue and punycoding the domain name is not necessarily the only option. It is one, for sure, but we could also do "phishing warning" infobars or interstitials for top-level (document) urls that meet some suspicion criteria (e.g. bug 1507582 is one option). Or wrt this bug in particular we could declare combining marks to be always suspicious and assume the number of legitimately registered domains using that feature is essentially nil. But of course in many cases the pre-composed versions of the characters are just as spoofy so that wouldn't be a complete solution.

Comment 6

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

Attachment: Bug 1473911 - Fix URL spoofing combining dot + ijk r=dveditz

Depends on D161782

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7b91b96b9f37
Fix URL spoofing combining dot + ijk r=necko-reviewers,jesup

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/53510777f0db
Fix URL spoofing combining dot + ijk r=necko-reviewers,jesup

Comment 9

[Norisz Fay [:noriszfay]]

Backed out for causing xpcshell failures on test_idn_spoof.js

Backout link

Push with failures

Failure log

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/abe9af35df92
Fix URL spoofing combining dot + ijk r=necko-reviewers,jesup

Comment 11

[Marian-Vasile Laza]

https://hg.mozilla.org/mozilla-central/rev/abe9af35df92

Comment 12

[Ryan VanderMeulen [:RyanVM]]

This was reverted from Beta109 due to the ICU72 update it depends on being backed out for causing bug 1806042. For now, it remains in place for 110+, but that may need to be revisited in the future.
https://hg.mozilla.org/releases/mozilla-beta/rev/7deaef0e20e3

Comment 13

[Daniel Veditz [:dveditz]]

"depends on" bug 1790163 landing first because this patch includes changes to a test that doesn't exist until that one lands