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

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Sep 2017
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Bug-Security

Sign in to add a comment

Issue 745580: Security: Chrome extensions UI does not respect IDN display policy

Reported by, Jul 18 2017

Issue description

Google Chrome doesn't display IDNs as punycode in the "Add Extension" popup window displayed to users when they choose to install a Chrome extension. Additionally, IDNs are not displayed as punycode in the "Details" popup window in chrome://extensions/ - leaving them vulnerable to IDN homograph attacks. Additionally, as users are not able to select text within these popup windows, there is no way for a user to easily check for and detect an IDN homograph attack by themselves.

Chrome Version: 59.0.3071.115 (Official Build) (64-bit) (cohort: Stable)
Operating System: Windows 10 Pro 1703 & Ubuntu 16.04.1

An attacker would exploit this vulnerability through a Chrome extension with attacker-owned IDNs in the permissions declaration of the manifest, for example:

  "permissions": [

Victims installing the malicious extension are prompted to accept the extension's ability to read and change data on domains that appear to be innocuous, unknowingly permitting an attacker to execute malicious scripts from these IDNs. I have attached a valid Chrome extension manifest.json file that demonstrates this vulnerability.

Thanks for your time.
378 bytes View Download

Comment 1 by, Jul 18 2017

Components: Platform>Extensions
Summary: Security: Chrome extensions UI does not respect IDN display policy (was: Security: Chrome extensions bypass IDN policy checks)
Interesting. I'm not convinced that this is very interesting from a security point-of-view; the permission so granted would allow the extension to interact with pages that use spoofy IDN domains, but this wouldn't impact the omnibox in any way, and the origin of the extension itself isn't in any way misrepresented.

Comment 2 by, Jul 18 2017

Any thoughts Devlin?

Comment 3 by, Jul 18 2017

I'm also dubious about the security aspect of this (accessing spoofy-google actually sounds quite a bit less harmful than accessing real-google and stealing my data), but I'd be supportive of a change for consistency and clarity.

mkwst@, is there a preferred canonicalization function to use for things like this?

Comment 4 by, Jul 18 2017

I believe url_formatter::FormatUrlForSecurityDisplay is the function to use.

Comment 5 by, Jul 18 2017

Labels: Security_Severity-Low Security_Impact-Stable M-61 Pri-2
As I understand this, the impact is that a user might think they're agreeing to execute scripts from, and the extension will actually execute scripts from Now there are a number of qualifiers on this including that the extension could just include the scripts directly, and that it's bound to it's own spoofed domain name. I'll tag this as low.

Comment 6 by, Jul 18 2017

Status: Available (was: Unconfirmed)

Comment 7 by, Jul 18 2017

Labels: OS-Chrome OS-Linux OS-Mac OS-Windows

Comment 8 by, Jul 19 2017

RE #5: I thought the Permissions node in the manifest gates what domains the extension is allowed to access and script /against/, not what domains the extension is allowed to source SCRIPTS /from/. I wasn't aware of restrictions (aside from the manifest's CSP, if any) on where an extension can source script from?

Comment 9 by, Jul 19 2017

RE #8 this is a fair point, in my testing it seems the CSP is the only factor inhibiting an extension from loading scripts from a third-party domain. However, an attacker still has the ability to coerce users into accepting permissions to access and modify content on domains they were not expecting which could aid in deception attacks.

Comment 10 by, Jul 19 2017

Project Member
Status: Assigned (was: Available)

Comment 11 by, Aug 28 2017

catmullings@, this could be a good one for you to tackle.

Comment 12 by, Aug 30 2017

Status: Started (was: Assigned)

Comment 13 by, Sep 1 2017

Project Member
The following revision refers to this bug:

commit 504e0c45030f76bffda93f0857e7595216d6e7a4
Author: Catherine Mullings <>
Date: Fri Sep 01 01:04:46 2017

Ensure IDN domains are in punycode format in extension host permissions

Today in extension dialogs and bubbles, IDN domains in host permissions
are not displayed in punycode format. There is a low security risk that
granting such permission would allow extensions to interact with pages
using spoofy IDN domains. Note that this does not affect the omnibox,
which would represent the origin properly.

To address this issue, this CL converts IDN domains in host permissions
to punycode format.

Bug:  745580 
Change-Id: Ifc04030fae645f8a78ac8fde170660f2d514acce
Commit-Queue: catmullings <>
Reviewed-by: Istiaque Ahmed <>
Reviewed-by: Tommy Li <>
Cr-Commit-Position: refs/heads/master@{#499090}

Comment 14 by, Sep 1 2017

Status: Fixed (was: Started)

Comment 15 by, Sep 1 2017

Project Member
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify

Comment 16 by, Sep 5 2017

Labels: -M-61 M-62

Comment 17 by, Sep 11 2017

Labels: reward-topanel

Comment 18 by, Sep 18 2017

Labels: -reward-topanel reward-0
The VRP panel look at look at this bug, but I'm sorry to say declined to reward (as is usually the case for low severity bugs).  But thanks for the report!

Comment 19 by, Oct 10 2017


Comment 20 by, Oct 10 2017


Comment 21 by, Oct 16 2017

Labels: Release-0-M62

Comment 22 by, Oct 18 2017

Labels: CVE-2017-15394

Comment 23 by, Dec 8 2017

Project Member
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

Comment 24 by, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment