Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 683314 Security: Whole-script confusable domain label spoofing (Cyrillic)
Starred by 14 users Reported by wrepr...@slicealias.com, Jan 20 Back to list
Status: Fixed
Owner:
Closed: Mar 24
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security


Hotlists containing this issue:
IDN-Spoofing


Sign in to add a comment
See https://www.xn--80ak6aa92e.com/ - if you compare with https://www.apple.com/, URL looks identical on Windows and Linux. On OS X, the font is slightly different, and it is potentially possible to distinguish between the two.

The domain xn--80ak6aa92e.com is currently proxying requests to apple.com to demonstrate how difficult it is to distinguish the malicious domain. I will  take it offline in the near future.

This issue also exists in Firefox and has been reported to them as well. On Safari, the URL does not appear as "apple.com", likely because Safari interprets some of the characters as belonging to a different language.
 
Components: UI>Localization UI>Browser>Omnibox
Labels: Team-Security-UX Security_Impact-Stable OS-All
Status: Available
Cc: lgar...@chromium.org meacer@chromium.org est...@chromium.org
For reference:

>>> x = "аррӏе"
>>> x.decode("utf-8")
u'\u0430\u0440\u0440\u04cf\u0435'

All Cyrillic (http://www.fileformat.info/info/unicode/char/0435/index.htm).

I had thought that we had a system in which, if your normal locale/language settings indicate you use a language that does not use (e.g.) Cyrillic, then we'd show Punycode? But Cyrillic users would see the Cyrillic? Did that regress, or am I misremembering?
Components: UI>Security>UrlFormatting
Owner: mgiuca@chromium.org
Status: Assigned
mgiuca@, are you the right person to take a look at this?
Cc: mgiuca@chromium.org
Owner: js...@chromium.org
#0:

> The domain xn--80ak6aa92e.com is currently proxying requests to apple.com to demonstrate how difficult it is to
> distinguish the malicious domain. I will  take it offline in the near future.

If you want to, in good faith, demonstrate a vulnerability like this, you should not proxy to the real site; that can be seen as an actual phishing attempt. Instead just show a simple page that demonstrates you were able to register the domain. If you don't publish the link anywhere, I *believe* this will not run afoul of our responsible disclosure rule for reporting bugs.

#2 Python 2's Unicode support makes me sad.

>>> x = "аррӏе"
>>> print(ascii(x))
'\u0430\u0440\u0440\u04cf\u0435'

These are all Cyrillic confusables with the ASCII letters "apple". This is what's known as a "whole-script confusable" (not mixing letters from different scripts). It's very hard to stop this by technical means since there's nothing intrinsically wrong with it; it's just a collection of Cyrillic letters like any Russian word.

This is a well-known problem which used to be documented here:
https://www.chromium.org/developers/design-documents/idn-in-google-chrome
but that section was recently removed because it was out of date.

> I had thought that we had a system in which, if your normal locale/language
> settings indicate you use a language that does not use (e.g.) Cyrillic, then
> we'd show Punycode? But Cyrillic users would see the Cyrillic? Did that
> regress, or am I misremembering?

That system has been gone for about a year now (jshin did it). I believe the rationale was a) for compatibility with Firefox, b) because it meant all users got a different experience and c) it didn't actually stop exploits, just segmented which users were exploitable.

Anyway, there has been an internal discussion on this very topic over the past week. It's clear that this is a problem but there is no easy fix (other than removing Cyrillic characters from domains entirely).

I think in the short term this is WontFix (might be a dupe). Assigning to Jungshik who knows this stuff.
To summarize my comment from the internal discussion: I think the primary action here should be that the browser vendors, as a group, have a formal dialog with registrars to (a) report individual bad cases and (b) convince registrars to enact policies to prevent registration of such confusables.

The registrar for .com should not allow "apple.com" and "аррӏе.com" to be registered to different organizations.

Separately, perhaps there is a secondary solution where the Safe Browsing pipeline can look for domain names that are whole-script confusable with other known domain names and use that as a very strong signal of bad intent.

I don't know who should take point on these actions, but I think they amount to more than "WontFix".
The growing nature of unicode might make it difficult for registrars to maintain a blacklist and block malicious domains. There are also existing domains such as http://xn--80aj.com/ that may be confusing but serve a legitimate purpose.

What about handling punycode domains the Safari way (with a whitelist), as specified on https://www.chromium.org/developers/design-documents/idn-in-google-chrome. 
Labels: Security_Severity-Medium
> There are also existing domains such as http://xn--80aj.com/ that may be
> confusing but serve a legitimate purpose.

What legitimate purpose does http://xn--80aj.com/ (еа.com) serve? Is that a legitimate Cyrillic domain?

> What about handling punycode domains the Safari way (with a whitelist)

We do have a whitelist. Essentially you're suggesting that we remove Cyrillic and Greek characters from the list. I'm not sure we want to go down that path.
Registrars are likely not going to revoke existing domains that are confusing such as the ea.com domain, and the ideal solution should be make it possible to distinguish existing domains that are identical. What about displaying Cyrillic and Greek characters with a different style on Linux and Windows, the way it is already done on OS X?
I don't know what you mean by "with a different style".  You mean, in a different font?  Or were you referring to Safari using punycode in comment 0?  Users won't notice/understand the meaning of the former, and the latter is intentional.
Project Member Comment 11 by sheriffbot@chromium.org, Jan 23
Labels: M-56
Project Member Comment 12 by sheriffbot@chromium.org, Jan 23
Labels: Pri-1
Would this bug be more correctly titled: "Regression: Whole-script confusable labels allowed by IDN Policy"?

With a regressing CL of https://bugs.chromium.org/p/chromium/issues/detail?id=336973#c34 ?
Summary: Security: Whole-script confusable domain label spoofing (was: Security: IDN Phishing on Windows and Linux)
I don't think this is really a regression -- for example anyone who had Russian as a language would've been subject to this spoof before that change. This just makes the policy consistent for all users and therefore exposes all users to the whole-script confusable spoofing. I'll retitle it though.
Cc: markda...@google.com sffc@google.com
Blocking: 687286
Issue 687286 has been merged into this issue.
Cc: markbemb...@gmail.com
+CC reporter from Issue 687286.
Project Member Comment 19 by sheriffbot@chromium.org, Feb 9
jshin: Uh oh! This issue still open and hasn't been updated in the last 14 days. This is a serious vulnerability, and we want to ensure that there's progress. Could you please leave an update with the current status and any potential blockers?

If you're not the right owner for this issue, could you please remove yourself as soon as possible or help us find the right one?

If the issue is fixed or you can't reproduce it, please close the bug. If you've started working on a fix, please set the status to Started.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Status: Started
https://codereview.chromium.org/2683793010/ has a draft CL to check for domains entirely made up of a small set of Cyrillic letters that look like Latin letters. 

When the check is on unconditionally (PS #1), about 800 domains in .рф is blocked out of 861657 IDNs (as of March 2016) in рф (0.1%). 

PS #2 applies the check only to domains with a non-IDN TLD (com, net, uk, etc). I'll collect the stat against com and a couple of other gTLDs. 
Project Member Comment 21 by sheriffbot@chromium.org, Mar 10
Labels: -M-56 M-57
Labels: -M-57 M-59
@jshin, could you provide an update here? are you on track for M59 for this short-term fix?
Project Member Comment 23 by bugdroid1@chromium.org, Mar 23
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/08cb718ba7c3961c1006176c9faba0a5841ec792

commit 08cb718ba7c3961c1006176c9faba0a5841ec792
Author: jshin <jshin@chromium.org>
Date: Thu Mar 23 21:25:32 2017

Block domain labels made of Cyrillic letters that look alike Latin

Block a label made entirely of Latin-look-alike Cyrillic letters when the TLD is not an IDN (i.e. this check is ON only for TLDs like 'com', 'net', 'uk', but not applied for IDN TLDs like рф.

BUG= 683314 
TEST=components_unittests --gtest_filter=U*IDN*

Review-Url: https://codereview.chromium.org/2683793010
Cr-Commit-Position: refs/heads/master@{#459226}

[modify] https://crrev.com/08cb718ba7c3961c1006176c9faba0a5841ec792/components/url_formatter/url_formatter.cc
[modify] https://crrev.com/08cb718ba7c3961c1006176c9faba0a5841ec792/components/url_formatter/url_formatter_unittest.cc

Status: Fixed
Fixed in the trunk
Project Member Comment 25 by sheriffbot@chromium.org, Mar 24
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Components: -UI>Localization UI>Internationalization
Labels: reward-topanel
Labels: -reward-topanel reward-unpaid reward-2000
Congratulations! The VRP panel decided to award $2,000 for this report.  A member of our finance team will be in touch shortly to arrange payment.  Cheers!
Labels: -reward-unpaid reward-inprocess
Labels: Merge-Request-58
Requesting merge per email conversation.
Project Member Comment 32 by sheriffbot@chromium.org, Apr 14
Labels: -Merge-Request-58 Merge-Review-58 Hotlist-Merge-Review
This bug requires manual review: We are only 10 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Merge-Review-58 Merge-Approved-58
Per comment 31, approving for M58. Please merge. 
Labels: M-58
Cc: rivalitman@google.com
Cc: awhalley@chromium.org
Per comment #36 if this is already merged to M58, please apply "merge-merged-3029" label and remove "Merge-Approved-58" label. Thank you.
Project Member Comment 38 by sheriffbot@chromium.org, Apr 18
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!

If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.

Thanks for your time! To disable nags, add the Disable-Nags label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: -Hotlist-Merge-Review -Merge-Approved-58 merge-merged-3029
I was expecting bugdroid to do its thing, ha well.

Double checked the cherry pick is showing up on https://chromium.googlesource.com/chromium/src/+log/refs/branch-heads/3029 so I think we're all good.
sorry about the delay. I'm merging to m58 now. 

ooops. it's already merged. 

Labels: Release-0-M58
Labels: -Restrict-View-SecurityNotify allpublic
Opening up bug since the issue is public.
Labels: CVE-2017-5060
How would you guys feel about using a pre-generated list of homoglyphs (https://github.com/codebox/homoglyph) to test domains vs. the Alexa 1000 top domains?

Basically -- render in punycode any domain that "looks like" a top site, but isn't really.
Comment 46 by mor...@mertinkat.net, Apr 24 (4 days ago)
Adding cyrillic character "к"[1] which looks like latin "k" to the "cyrillic_letters_latin_alike_" variable[2] would be a good idea.

>>> x = "ӏіпкеԁіп.com"
>>> x.decode("utf-8")
u'\u04cf\u0456\u043f\u043a\u0435\u0501\u0456\u043f.com'


[1] http://www.fileformat.info/info/unicode/char/043a/index.htm
[2] https://cs.chromium.org/chromium/src/components/url_formatter/url_formatter.cc?type=cs&q=cyrillic_letters_latin_alike_+package:%5Echromium$&l=335
Comment 47 by markda...@google.com, Apr 24 (4 days ago)
In practice it looks distinct enough to not be a problem; look at "looк
кids" to see how they look strange enough to alert people.

Mark
Comment 48 Deleted
Comment 49 by mor...@mertinkat.net, Apr 24 (4 days ago)
ъut thҽп somҽ othҽг cyrillic chaгactҽгs aгe also distiпct ҽпough (like ъ, Ь, ҽ)...
Comment 50 by tobias...@gmail.com, Apr 24 (4 days ago)
@ comment 49: I think we need a list of all fonts used for the omnibar over the various OSes. That it looks distinctive on your PC doesn't mean it does for everybody
Comment 51 by lgar...@chromium.org, Apr 24 (4 days ago)
re: last few comments: This bug is about perfect spoofs. Other near-homoglyphs are Issue 703750.
Comment 52 by mor...@mertinkat.net, Apr 24 (4 days ago)
Ok guys, this is only for "perfect spoofs"? Well, then I don't understand why you added these characters: "ъЬҽпгѵѡ". These are not perfect spoofs with the font used in the address bar in Chrome 58 on Windows 7 and 10.

The "к" character is not a perfect spoof either but might be misleading for an unexperienced user just like the characters "ъЬҽпгѵѡ".
And (like comment #50 said) it also depends on the font used in Chrome which means that there might be a perfect spoof or not for any of the given characters in "cyrillic_letters_latin_alike_".

That said I'd appreciate if I could have access to issue 703750.

Thanks!

Comment 53 by lgar...@chromium.org, Apr 24 (4 days ago)
Summary: Security: Whole-script confusable domain label spoofing (Cyrillic) (was: Security: Whole-script confusable domain label spoofing)
Comment 54 by mor...@mertinkat.net, Apr 26 (2 days ago)
Would you accept a pull request to add that character? Or shall we just leave it as inconsistent as it is?

Not sure what to do and I don't have access to 703750 in case this is not the right place to discuss cyrillic/latin similarities.
Comment 55 by meacer@chromium.org, Apr 26 (2 days ago)
Comment #54: I opened up bug 703750.
Sign in to add a comment