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

Issue 714196 link

Starred by 4 users

Security: Domain spoofing thanks to U+0F8C rendered as 'space' on Mac

Reported by, Apr 21 2017

Issue description

The character U+0F8C (TIBETAN SIGN INVERTED MCHU CAN) when used in a domain name in Chrome looks just like a space.

This can be abused to spoof a legitimate domain followed by a chain of the character, e.g. "<U+0F8C x 52>".

I have created a domain which is SSL-enabled and looks just like when your Chrome window is now wide enough to cover the whole address. The DNS limits makes it impossible to add arbitrary number of U+0F8C chars in the address bar. As a workaround, the attacker might add just a dot, hoping that the end-user will not notice it, for example:

I have attached a screenshot of a SSL-enabled domain using 53 U+0F8C characters.

54.3 KB View Download

Comment 1 by, Apr 21 2017

Components: UI>Browser>Omnibox UI>Security>UrlFormatting UI>Internationalization
Labels: Security_Severity-Medium Security_Impact-Stable OS-Mac
Status: Assigned (was: Unconfirmed)
Thanks for the report. This seems Mac specific, as I'm seeing proper rendering of U+0F8C on Linux and Windows. I'm tentatively assigning severity-medium, but the fact that the attack relies on the omnibox being narrow could make this low severity as well.

jshin: Can you please take a look?
10.4 KB View Download
16.6 KB View Download

Comment 2 by, Apr 21 2017

Components: UI>GFX
Owner: ----
Status: Available (was: Assigned)
Hmmm... Indeed, it's Mac-specific.  I wonder why Mac omnibox does not use Mac's last resort font if it can't find any font covering U+0F8C. It's an "gfx" bug on Mac to render U+0F8C as a space. 

BTW, U+0F8C is allowed as an 'Identifier' ( : unicode set utility is buggy in saying that it's not allowed. The canonical source is which has this line:


Comment 3 by, Apr 21 2017

Summary: Security: Domain spoofing thanks to U+0F8C rendered as 'space' on Mac (was: Security: Domain spoofing thanks to U+0F8C character)
Not knowing who works on the text rendering part of GFX in the UI these days, adding a few people who might know. 

Comment 4 by, Apr 22 2017

I think this rendering is largely up to AppKit. There might be a workaround we can do in OmniboxViewMac::ApplyTextAttributes()$&l=584

the status bubble also renders spaces, and so do other NSTextFields.

Safari renders spaces when editing, but drops back to rendering 'aaaa' when the URL is committed.

MacViews uses a (kinda ugly) "missing glyph" character.
28.2 KB View Download
25.6 KB View Download
139 KB View Download
Project Member

Comment 5 by, Apr 22 2017

Labels: M-58
Project Member

Comment 6 by, Apr 22 2017

Labels: Pri-1

Comment 7 by, Apr 25 2017

rsesek, mgiuca: Any thoughts? Can you suggest an owner for this bug?

Comment 8 by, Apr 25 2017

tapted, is Views going to be the default on Mac any time soon? Maybe that will fix the fallback-font aspect of this bug?

The remaining part seems to be about what happens when the window isn't wide enough, in which case we should be following It seems like we're not?

How does iOS behave given this domain name?

Comment 9 by, Apr 25 2017

Views won't be replacing this part of the browser any time soon, no.

Maybe sdy@ could help look at this? Also +shrike as TL for Mac.
Status: Assigned (was: Available)
Hello lgrey@ - can you take a look at this important security bug?

Comment 11 by, Apr 26 2017

Looks like iOS correctly displays a "missing glyph" box. I think the root cause is a font bug in macOS (as in: the glyph is "there" but has no data.) 

Safari doesn't decode the Punycode in this case, but I'm not sure how they know not to. suggests this character may not be allowed in a domain, so maybe they maintain a whitelist like this?

palmer@ would eliding from the left be a sufficient fix for this? 

We could also try substituting this code point's glyph to the "missing" glyph manually as well, but I think U+0F8{D,E,F}/U+0F8{9,A} would have the same issue, sticking just to Tibetan script, so I would imagine there's more out there.
Safari is falling back to Punycode for display of the committed URL, so why doesn't Chrome do that in this case? If I copy the URL displayed in the Omnibox on Mac, I get the Punycode-encoded domain, so why aren't we using that for display as well?

Re: #11: No, I don't think eliding from the left to be sufficient, because we always want to display the origin. With left-elide, a really long URL would have only the tail of the path be visible.
Re #11/#12: Isn't comment #2 noting that the IDN rules allow this display of this character? Our IDNSpoofChecker::SetAllowedUnicodeSet function does tactically block a few more characters, but U+0F8C doesn't seem to meet the same criteria insofar as there's nothing "wrong" with the character, but just the font.

Safari appears to use a script whitelisting approach; even using other Tibetan characters and setting the OS language to Tibetan doesn't seem to allow rendering in Unicode.

Chrome always copies urls in punycoded form (presumably for interop with other applications).
lgrey@ found that in RFC 5892 that the point is "reserved"/UNASSIGNED, but that pre-dates this character's introduction into Unicode by a few months.

The problem is indeed with the font: the glyph exists in the font but it renders blank. We may just have to blacklist these points on Mac, since the glyph isn't technically missing. Then we have to hope other characters don't have this same issue...
From, which lgrey@ pointed me at yesterday, it seems like there are probably several other characters rendering blank.
Just another datapoint, it doesn't appear that Tibetan is on the list of supported languages for the default system font (via CTFontCopySupportedLanguages). Tested this in Python:

>>> import CoreText as CT
>>> import AppKit
>>> font = AppKit.NSFont.systemFontOfSize_(0)
>>> font
".AppleSystemUIFont 13.00 pt. P [] (0x7fe71b113de0) fobj=0x7fe71b113c30, spc=3.59"
>>> langs = CT.CTFontCopySupportedLanguages(font)
>>> langs.containsObject_("bo")
>>> langs.containsObject_("tib")
>>> langs.containsObject_("bod")

I don't know if we we should use that as a test for anything, though. Because while a font that does support Tibetan does exist on macOS:

>>> font_tib = CT.CTFontCreateWithName("Kailasa", 0, None)
>>> font_tib
"Kailasa 12.00 pt. P [] (0x7fe717e0aec0) fobj=0x7fe717e0aec0, spc=4.73"
>>> CT.CTFontCopySupportedLanguages(font_tib)

... it also renders U+0F8C as a blank.

Comment 17 by, Apr 27 2017

When I paste U+0F8C into TextEdit it changes the font to "Songti SC". In character palette, it looks like all the Songti include it (but render as blank).
Nor does it display in the system UI font used explicitly for Tibetan, as derived by:

>>> CT.CTFontCreateUIFontForLanguage(CT.kCTFontUIFontLabel, 0, "bo")
".SFNSText 10.00 pt. P [] (0x7fe71b129240) fobj=0x7fe71b129240, spc=2.94"

I haven't been able to find a font that can display this glyph on Mac, so I think blacklisting this series of glyphs on Mac is probably the right way to go.

jshin: WDYT?

Comment 19 by, Apr 29 2017

Well, the character in question is rendered like 'space' even in HTML because one of Chinese fonts on Mac makes a false claim that it supports the character but has just an  blank glyph for that. 

This should be reported to Apple. It's a bug in that Chinese font. 

Comment 20 by, Apr 29 2017

See  and inspect where that character is supposed to be with DOM inspector. 'Kaiti SC' claims that it supports the character, but it does not. There are other Chinese fonts (Mac OS bundled fonts) that made the same false claim. 

Comment 21 by, Apr 29 2017

> because one of Chinese fonts on Mac makes a false claim that it supports the character but has just an  blank glyph for that. 

There are more than one broken Chinese fonts making that false claim. Perhaps, need to examine other fonts as well to see if how many characters are falsely claimed to be supported by those fonts. 
Filed rdar://31914563 with Apple.

Can we still do something on our end to mitigate this?
Friendly ping. Since it's security fix-it week, is there anything we can do in Chrome to address this? (Blacklisting as rsesek suggested in comment 18?)

If there's nothing that can be done in Chrome, perhaps we should change this to Status=ExternalDependency.
Just for the record: I've reported the same issue to Mozilla and, apart from reporting the bug to Apple as well, they decided to blacklist the offending characters.

This seems a sane approach for me since we don't really know how long it's going to take Apple to fix it while the blacklisting could be done right away.

Status: Started (was: Assigned)
Hello rsesek@,

lgrey@ believes there are other characters that are rendered blank - can you check with him (if you haven't already) so that they are all blacklisted?

Re: #24: Thanks for the additional information. We've also reported it to Apple (in #22) and will blacklist the codepoint in Chrome.

Re: #26: Yes, I have been working with lgrey@ on this. I was worried about the "known unknowns" problem, so I wrote a small program to iterate over all the Unicode characters between (0x0000,0xFFFF) in the default system font, drawing each to find any that rendered blank. From that set, I dropped anything whose Unicode character name contains the following substrings:

empty_chars \
    .pipe(drop_if_contains('<control>')) \
    .pipe(drop_if_contains('SPACE')) \
    .pipe(drop_if_contains('INVISIBLE')) \
    .pipe(drop_if_contains('ISOLATE')) \
    .pipe(drop_if_contains('LEFT-TO-RIGHT')) \
    .pipe(drop_if_contains('RIGHT-TO-LEFT')) \
    .sort_index() \

The remaining characters that draw as blank in the system font are:

00AD                                 SOFT HYPHEN
034F                   COMBINING GRAPHEME JOINER
0605                    ARABIC NUMBER MARK ABOVE
061C                          ARABIC LETTER MARK
0620                  ARABIC LETTER KASHMIRI YEH
065F                     ARABIC WAVY HAMZA BELOW
180E                   MONGOLIAN VOWEL SEPARATOR
2000                                     EN QUAD
2001                                     EM QUAD
200C                       ZERO WIDTH NON-JOINER
2028                              LINE SEPARATOR
2029                         PARAGRAPH SEPARATOR
2060                                 WORD JOINER
2061                        FUNCTION APPLICATION
206E                       NATIONAL DIGIT SHAPES
206F                        NOMINAL DIGIT SHAPES
2800                       BRAILLE PATTERN BLANK
3164                               HANGUL FILLER
A4A2                              YI RADICAL ZUP
A4A3                              YI RADICAL CYT
A4B4                             YI RADICAL NZUP
A4C1                              YI RADICAL ZUR
A4C5                             YI RADICAL NBIE
From the above list of characters, the only ones that need to be explicitly blacklisted I think are the 0F8C - 0FDA range. The remainder are already handled appropriately by our IDN system.
Re #27, nice work, Robert.
Project Member

Comment 30 by, May 9 2017

The following revision refers to this bug:

commit bccbe7c22a38f68da0c4d0bb9258060f2554e318
Author: rsesek <>
Date: Tue May 09 19:31:02 2017

Remove a small range of Tibetan characters from the allowed IDN set on Mac.

These characters do not display in the default macOS system font, despite the
font reporting that the glyphs are present.

BUG= 714196 

Cr-Commit-Position: refs/heads/master@{#470407}


Status: Fixed (was: Started)
Project Member

Comment 32 by, May 10 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: reward-topanel
Labels: -reward-topanel reward-unpaid reward-2000
Congratulations michal@! 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.

*** Boilerplate reminders! ***
Please do NOT publicly disclose details until a fix has been released to all our users. Early public disclosure may cancel the provisional reward. Also, please be considerate about disclosure when the bug affects a core library that may be used by other products. Please do NOT share this information with third parties who are not directly involved in fixing the bug. Doing so may cancel the provisional reward. Please be honest if you have already disclosed anything publicly or to third parties. Lastly, we understand that some of you are not interested in money. We offer the option to donate your reward to an established charity. If you prefer this option, let us know and we will also match your donation - subject to our discretion. Any rewards that are unclaimed after 12 months will be donated to a charity of our choosing.
Labels: -reward-unpaid reward-inprocess
When are you planning to release the patch in a release?

I'm asking since new Firefox has been released with exactly the same issue ( ), which means it is now pretty easy to construct an "exploit" for Chrome basing on the patch for Firefox.

This is slated for release in M60.

Comment 39 by, Jun 14 2017

Hmm... we could have merged this to M59 branch. It's not too late. 

 bug 725660  is similar (one Arabic character  needs to be blocked on Mac). 

rsesek@: what do you think of merging to M59 branch? 
Labels: Merge-Request-59
It would be safe to merge, so let's ask.
Labels: -Merge-Request-59 Merge-Approved-59
Since merge is safe, been in Dev for over a month, approving merge for M59. 
Project Member

Comment 42 by, Jun 14 2017

Labels: -merge-approved-59 merge-merged-3071
The following revision refers to this bug:

commit bf14cbf2c61544fed2d02a78a77cad0f04164e41
Author: Robert Sesek <>
Date: Wed Jun 14 19:37:32 2017

Remove a small range of Tibetan characters from the allowed IDN set on Mac.

These characters do not display in the default macOS system font, despite the
font reporting that the glyphs are present.

BUG= 714196

(cherry picked from commit bccbe7c22a38f68da0c4d0bb9258060f2554e318)

Cr-Original-Commit-Position: refs/heads/master@{#470407}
Change-Id: I96f412f602bf035d079caa0251ce3bc0de00181d
Reviewed-by: Robert Sesek <>
Cr-Commit-Position: refs/branch-heads/3071@{#788}
Cr-Branched-From: a106f0abbf69dad349d4aaf4bcc4f5d376dd2377-refs/heads/master@{#464641}

Comment 43 by, Jun 14 2017

Thanks !

Labels: Release-1-M59
Labels: -M-58 M-59
Labels: CVE-2017-5089
Project Member

Comment 47 by, Aug 16 2017

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-2017-13828
Labels: CVE_description-submitted
Labels: idn-spoof

Sign in to add a comment