New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 756456 link

Starred by 2 users

Issue metadata

Status: Fixed
Closed: Oct 2017
EstimatedDays: ----
NextAction: ----
OS: Windows , Mac
Pri: 2
Type: Bug-Security

Blocked on:
issue 726950

Sign in to add a comment

Security: IDN domain spoof with unicode (U+0F37 U+0F84)

Reported by, Aug 17 2017

Issue description

IDN domain google+(U+0F37).com and google+(U+0F84).com ,display does not use punycode encoding in Chrome ,and in browser tab, the two characters are hidden.

Chrome Version: 60.0.3112.101 stable (64-bit), 62.0.3184.0 canary (64-bit)
Operating System: MAC OS 10.12.5/10.13


function aa(){'','new','width=800,height=600');

function bb(){'','new1','width=800,height=600');

<button onclick='aa()'>dddd</button>
<button onclick='bb()'>dddd</button>
113 KB View Download
113 KB View Download

Comment 1 by, Aug 17 2017

Components: UI>Security>UrlFormatting UI>Internationalization
Labels: Security_Severity-Medium Security_Impact-Stable OS-Mac OS-Windows Pri-1
Status: Assigned (was: Unconfirmed)
Repros on Windows as well.
Screen Shot 2017-08-17 at 4.59.32 PM.png
57.3 KB View Download
Project Member

Comment 2 by, Aug 18 2017

Labels: M-61

Comment 3 by, Aug 21 2017

Sigh.....   I wish U+25CC (dotted circle) were used across the board when a base character and a combining mark belong to different scripts (the condition is a bit more complex, but the gist is that).  

I thought at least Blink uses U+25CC (even though Omnibox - native layout - does not), but it does not on my Ubuntu box (DejaVu Sans Mono for Latin and Tibetan Machine Uni for Tibetan). Perhaps, the latter font does not have U+25CC. 

google༷.com   (U+0F37 after 'e'). 

Filed . 

In the meantime, this issue strengthens an argument for going back to 'Highly Restrictive script mixing' (only allow mixing of CJK + Latin).  

Wait...   examples in this bug report cannot be registered at least for Verisign-controlled TLDs because it violates Verisign's script mixing rules.  

See .

Comment 4 by, Aug 21 2017

Labels: -Security_Severity-Medium Security_Severity-Low
Given the last para in the previous comment, security risk is rather low and I'm even tempted to open up this issue to the public. 

Project Member

Comment 5 by, Aug 22 2017

Labels: -Pri-1 Pri-2

Comment 6 by, Aug 29 2017

Blockedon: 726950
Labels: -M-61

Comment 7 by, Sep 25 2017

 bug 726950  is about U+0F35 after a Latin base character..
Project Member

Comment 8 by, Oct 4 2017

The following revision refers to this bug:

commit fd34ee82420c5e5cb04459d6e381944979d8e571
Author: Jungshik Shin <>
Date: Wed Oct 04 23:25:49 2017

Change the script mixing policy to highly restrictive

The current script mixing policy (moderately restricitive) allows
mixing of Latin-ASCII and one non-Latin script (unless the non-Latin
script is Cyrillic or Greek).

This CL tightens up the policy to block mixing of Latin-ASCII and
a non-Latin script unless the non-Latin script is Chinese (Hanzi,
Bopomofo), Japanese (Kanji, Hiragana, Katakana) or Korean (Hangul,

Major gTLDs (.net/.org/.com) do not allow the registration of
a domain that has both Latin and a non-Latin script. The only
exception is names with Latin + Chinese/Japanese/Korean scripts.
The same is true of ccTLDs with IDNs.

Given the above registration rules of major gTLDs and ccTLDs, allowing
mixing of Latin and non-Latin other than CJK has no practical effect. In
the meantime, domain names in TLDs with a laxer policy on script mixing
would be subject to a potential spoofing attempt with the current
moderately restrictive script mixing policy. To protect users from those
risks, there are a few ad-hoc rules in place.

By switching to highly restrictive those ad-hoc rules can be removed
simplifying the IDN display policy implementation a bit.

This is also coordinated with Mozilla. See .

BUG= 726950 ,  756226 ,  756456 ,  756735 ,  770465 
TEST=components_unittests --gtest_filter=*IDN*

Change-Id: Ib96d0d588f7fcda38ffa0ce59e98a5bd5b439116
Reviewed-by: Brett Wilson <>
Reviewed-by: Lucas Garron <>
Commit-Queue: Jungshik Shin <>
Cr-Commit-Position: refs/heads/master@{#506561}

Comment 9 by, Oct 4 2017

Status: Fixed (was: Assigned)
Project Member

Comment 10 by, Oct 5 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-NA
Labels: Release-0-M63 M-63
Labels: CVE-2017-15425
Project Member

Comment 14 by, Jan 11 2018

Labels: -Restrict-View-SecurityNotify allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot
Labels: CVE_description-missing
Labels: -CVE_description-missing CVE_description-submitted
Labels: idn-spoof

Sign in to add a comment