1164788 - The URL: "addons.mozilla.org" can be spoofed using Cyrillic letters.

Status: RESOLVED FIXED

(Core :: Internationalization, defect)

Description

[Parvinder]

Attachment: Spoofed URL.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150508094354

Steps to reproduce:

Step 1: Use the normal URL: https://аddоns.mоzillа.org/ .

Step 2: Replace the Latin "a" and Latin "o" in "аddоns.mоzillа" with the Cyrillic "а" and Cyrillic "о" to create the spoofed URL: https://аddоns.mоzillа.org/. 

Step 3: Enter the spoofed URL into the URL bar and press enter.


Actual results:

The spoofed homograph of "https://аddоns.mоzillа.org/" is seen as "https://аddоns.mоzillа.org/"  



Expected results:

Since the spoofed URL contains Cyrillic letters, the Punycode version of the spoofed URL should have resulted, but it did not, thereby creating the threat of a script spoofing attack.

Comment 1

[Parvinder]

The bug still exists, on the Firefox 38.0.1 update.

Comment 2

[Parvinder]

It is impossible for a human being to tell the difference between a homographic script spoofed URL and the non-spoofed URL. 

A person with malicious intent could easily use the spoofed link to trick someone, even the most cautious person, to download malware.

Comment 3

[Parvinder]

Attachment: Spoofed URL FF.png

I would also like to add that the word "addons" in https://addons.mozilla.org can also be spoofed, by replacing the Latin "a" and "o" with the Cyrillic "а" and "о."  

Here is the spoofed link: https://аddоns.mozilla.org 

I have also included a screenshot.

Comment 4

[Matt Wobensmith [:mwobensmith][:matt:]]

https://wiki.mozilla.org/IDN_Display_Algorithm#Algorithm

Comment 5

[Parvinder]

"Common + Inherited + Latin + any single other "Recommended" or "Aspirational" script except Cyrillic or Greek" From: https://wiki.mozilla.org/IDN_Display_Algorithm#Algorithm 


"Allow Latin with other Recommended or Aspirational scripts except Cyrillic and Greek"
From: http://www.unicode.org/reports/tr39/#Restriction_Level_Detection

Comment 6

[Matt Wobensmith [:mwobensmith][:matt:]]

Parvinder, I agree with you. I included the URL here just for reference. Give us a bit of time, we're looking into this and deciding how to rate it. Thank you for reporting!

Comment 7

[Matt Wobensmith [:mwobensmith][:matt:]]

We have a test from the original bug [1] that mixes Latin + Cyrillic. I'd think that it would have caught this case. Adding Simon here in case he wants to comment.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=722299

Comment 8

[Simon Montagu :smontagu]

This was by design in bug 722299 following https://wiki.mozilla.org/IDN_Display_Algorithm#Algorithm: .org is in the IDN domain whitelist, which means that we trust the TLD registration policies not to register mixed-script domains and don't apply our own checks. 

https://аddоns.mоzillа.ru _does_ display in punycode, and so does https://аddоns.mоzillа.org/ if you set network.IDN.use_whitelist to false in about:config.

Gerv, is this all accurate? Is this WONTFIX, or do we want to change anything today?

Comment 9

[Gervase Markham [:gerv]]

Firstly, the attack as described is not a real attack - the only people who could attack Mozilla would be Mozilla, because both domains have to be subdomains of mozilla.org, and Mozilla controls that part of the DNS. 

If you suggested an alternative attack, e.g. where the "o" in Mozilla was replaced by a Cyrillic letter, than you'd have to get that domain registration past the .org people, and they shouldn't allow it, by policy.

So I think that our way of doing things remains secure.

(In reply to Simon Montagu :smontagu from comment #8)
> This was by design in bug 722299 following
> https://wiki.mozilla.org/IDN_Display_Algorithm#Algorithm: .org is in the IDN
> domain whitelist, which means that we trust the TLD registration policies
> not to register mixed-script domains and don't apply our own checks. 

Simon: So the whitelist overrides the display algorithm, not just for the registered label ("mozilla" in this case), but for all labels in the name? It seems like we should really be applying the display algorithm to all labels below the registered label, at minimum, for consistency.

So perhaps it may now be time to turn off the whitelist, which remained only as a transitional measure. It seems that the new algorithm didn't cause significant problems that I've heard of. We would then be handling labels consistently across the board.

Gerv

Comment 10

[Simon Montagu :smontagu]

(In reply to Gervase Markham [:gerv] from comment #9)
> Firstly, the attack as described is not a real attack - the only people who
> could attack Mozilla would be Mozilla, because both domains have to be
> subdomains of mozilla.org, and Mozilla controls that part of the DNS. 
> 
> If you suggested an alternative attack, e.g. where the "o" in Mozilla was
> replaced by a Cyrillic letter, than you'd have to get that domain
> registration past the .org people, and they shouldn't allow it, by policy.
>
> So I think that our way of doing things remains secure.

FTR, the example given, https://аddоns.mоzillа.org/, has Cyrillic 'а' and 'о' in both 'аddоns' and 'mоzillа'.
  
> (In reply to Simon Montagu :smontagu from comment #8)
> Simon: So the whitelist overrides the display algorithm, not just for the
> registered label ("mozilla" in this case), but for all labels in the name?
> It seems like we should really be applying the display algorithm to all
> labels below the registered label, at minimum, for consistency.

This is a distinction that I don't remember ever coming up before, and I'm not sure how we can even tell which labels in a URL are below the registered label. Is it everything other than what is returned by nsIEffectiveTLDService::getBaseDomain, or is life more complicated?

I'm also not convinced that this proposal *increases* consistency ;-)

> So perhaps it may now be time to turn off the whitelist, which remained only
> as a transitional measure. It seems that the new algorithm didn't cause
> significant problems that I've heard of. We would then be handling labels
> consistently across the board.

I would have thought that the reasons for retaining the whitelist in https://wiki.mozilla.org/IDN_Display_Algorithm#Proposal still apply:
"a) removing it might break some domains which worked previously, and b) if a registry submits a good policy, we have the ability to give them more freedom than the default restrictions do", but perhaps consistency trumps that.

Comment 11

[Matt Wobensmith [:mwobensmith][:matt:]]

(In reply to Gervase Markham [:gerv] from comment #9)

> If you suggested an alternative attack, e.g. where the "o" in Mozilla was
> replaced by a Cyrillic letter, than you'd have to get that domain
> registration past the .org people, and they shouldn't allow it, by policy.

Do all domain registrars follow the same script-mixing rules w/r/t domain names as Firefox does?

Comment 12

[Gervase Markham [:gerv]]

(In reply to Matt Wobensmith from comment #11)
> Do all domain registrars follow the same script-mixing rules w/r/t domain
> names as Firefox does?

The ones on the whitelist do (or did, at the time they were added). The ones not on the whitelist are constrained by our algorithm, which we switched to when we realised the whitelist wouldn't scale. So they could let someone register a mixed-script name, but it wouldn't display properly in Firefox.

Gerv

Comment 13

[Simon Montagu :smontagu]

I forgot that we already have bug 843689 on removing the whitelist.

Comment 14

[Daniel Veditz [:dveditz]]

This bug does not need to be hidden. The security review for the new IDN algorithm identified this as a flaw with the whitelisting approach and that information is public at https://wiki.mozilla.org/Security/Reviews/IDN and led directly to the filing of bug 843689.

Comment 15

[Daniel Veditz [:dveditz]]

This was fixed by bug 1399939 in Firefox 58 or so.

Comment 16

[:Gijs (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #15)

This was fixed by bug 1399939 in Firefox 58 or so.

So should we close it as fixed? :-)

Comment 17

[Daniel Veditz [:dveditz]]

Missed a button, sorry :-)