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

NEW
Unassigned

Status

()

Core
Internationalization
3 years ago
3 years ago

People

(Reporter: Parvinder, Unassigned)

Tracking

38 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

3 years ago
Created attachment 8605725 [details]
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.
(Reporter)

Comment 1

3 years ago
The bug still exists, on the Firefox 38.0.1 update.
(Reporter)

Comment 2

3 years ago
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.
(Reporter)

Comment 3

3 years ago
Created attachment 8606827 [details]
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.
(Reporter)

Comment 5

3 years ago
"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
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!
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
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?
Flags: needinfo?(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
Flags: needinfo?(gerv)
Flags: needinfo?(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.
Flags: needinfo?(smontagu)
(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?
(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
I forgot that we already have bug 843689 on removing the whitelist.
Depends on: 843689
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.
Group: core-security
Status: UNCONFIRMED → NEW
Component: Untriaged → Internationalization
Ever confirmed: true
Product: Firefox → Core
You need to log in before you can comment on or make changes to this bug.