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

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
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.
Any thoughts Devlin?
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?
I believe url_formatter::FormatUrlForSecurityDisplay is the function to use.
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.
Status: Available (was: Unconfirmed)
Labels: OS-Chrome OS-Linux OS-Mac OS-Windows
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?
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.
Project Member

Comment 10 by, Jul 19 2017

Status: Assigned (was: Available)
catmullings@, this could be a good one for you to tackle.
Status: Started (was: Assigned)
Project Member

Comment 13 by, Sep 1 2017

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}

Status: Fixed (was: Started)
Project Member

Comment 15 by, Sep 1 2017

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Labels: -M-61 M-62
Labels: reward-topanel
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!
Labels: Release-0-M62
Labels: CVE-2017-15394
Project Member

Comment 23 by, Dec 8 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_description-submitted

Sign in to add a comment