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 2 users

Issue metadata

Status: Fixed
Closed: Jan 2017
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Security

Sign in to add a comment

Issue 677716: Security: Address spoofing in Omnibox with HTTPS lock

Reported by, Jan 1 2017

Issue description

Address spoofing in Omnibox with HTTPS lock

Chrome Version: Version 55.0.2883.87 (64-bit) stable
Operating System: Ubuntu 16.04.1 LTS


Open a new tab and navigate to the video)
This issue is similar to
Perhaps it only works on Linux because the pop-up window doesn't remove the focus from the Omnibox.


* This POC may not work because of different screen resolution. But a dedicated attacker could improve them given he has access to the victim's screen resolution.
142 KB View Download
1.2 MB View Download

Comment 1 by, Jan 1 2017

Components: UI>Browser>Omnibox
Labels: OS-Linux
Status: Untriaged (was: Unconfirmed)
Notably, the spoofed omnibox isn't the omnibox of the foreground window, but rather a background window.

Comment 2 by, Jan 2 2017

Labels: Security_Severity-Medium M-57 Security_Impact-Stable Pri-1
Status: Assigned (was: Untriaged)
palmer@: Can you take this, since you fixed a similar issue previously?

Comment 3 by, Jan 3 2017

Labels: Team-Security-UX
I don't work on security UX anymore. Passing to that crew...

Comment 4 by, Jan 10 2017

I think this is a pretty convincing spoof, though as comment 1 points out, an interaction with the background window would reveal the real origin.

Have poked around a little bit and it seems that focus is somehow ending up in the omnibox of the second tab, with the cursor at the end of the URL. No idea why yet, will continue poking tomorrow. +creis in case he has any thoughts.

(Couldn't repro on Mac, btw. But the behavior on Mac is a little odd: focus ends up in the omnibox of the second tab, but with the whole URL selected.)

Comment 5 by, Jan 10 2017

Components: UI>Browser>Navigation
Labels: Needs-Bisect
I see the similarity with  issue 567445 -- this is another case where FocusLocationBarByDefault is giving the omnibox focus when it shouldn't, thus scrolling the origin out of view and making the spoof possible.  Interesting that it affects the background tab this time, which is kind of a mitigating factor but I agree it's still a bad outcome.

Note: The repro doesn't fully work on Linux in M57.  In both 57.0.2970.0 Linux Dev and a debug build (57.0.2975.0), the background tab gets focus and is shown on top of the login popup.  Even if you put the fake login in that tab instead of a popup, the origin would become visible when you focus the password field to type in it.  (Maybe using an alert like  issue 567445  would work?)

Anyway, I did repro the bug in 55.0.2883.33.  A bisect would be useful to see when this behavior changed, and whether M56 is affected.

The actual bug itself appears to be in ShouldFocusLocationBarByDefault in, which returns true if a tab is committing the New Tab Page (chrome://newtab).  That function doesn't check whether the tab is actually the selected tab in the window!  As a result, it's giving focus to the attacker's tab in step 2 of the attack, after it sends the opener back from chrome_url_spoof_1.html to the NTP.  estark@, would you like to update that, or should I?

I've also attached the two attack files for posterity (noting that the attack from  issue 567445  is no longer available).
159 bytes View Download
87.8 KB View Download

Comment 6 by, Jan 11 2017

Status: Started (was: Assigned)
I've got a CL started for this.

Comment 7 by, Jan 12 2017

Project Member
The following revision refers to this bug:

commit 8f3a9a68b2dcdd2c54cf49a41ad34729ab576702
Author: creis <>
Date: Thu Jan 12 20:19:26 2017

Don't focus the location bar for NTP navigations in non-selected tabs.

BUG= 677716 
TEST=See bug for repro steps.

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


Comment 8 by, Jan 12 2017

Labels: M-56
Status: Fixed (was: Started)
Should be fixed in tomorrow's canary.  After that bakes for a day or so, I'll see about merging it to M-56.

Note that the change in behavior I mentioned in comment 5 was due to r426905, which changed how focus works.  That's present in M56, and it prevents the exploit from working as written.  As noted, though, there may be a different way to set up a spoof with this bug in M56.

Either way, this fix is probably worth merging to avoid any risk of a spoof, since the focus behavior is still problematic even after r426905.

Comment 9 by, Jan 12 2017

Labels: -Needs-Bisect

Comment 10 by, Jan 13 2017

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

Comment 11 by, Jan 13 2017

Labels: reward-topanel

Comment 12 by, Jan 17 2017

Labels: Merge-Request-56
Requesting merge of r443338 to M56.  This is a small, low-risk change that has baked on Canary for several days, and I've verified it on Linux Dev 57.0.2984.0.

Note that the exact spoof described in this bug doesn't work as is in M56 already (per comments 5 and 8), but I do think the bug is risky enough to make other types of spoofs possible, and we should likely merge it.

Comment 13 by, Jan 17 2017

Project Member
Labels: -Merge-Request-56 Merge-Review-56 Hotlist-Merge-Review
This bug requires manual review: We are only 13 days from stable.
Please contact the milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), gkihumba@(cros), bustamante@(desktop)

For more details visit - Your friendly Sheriffbot

Comment 14 by, Jan 18 2017

Labels: -Merge-Review-56 Merge-Approved-56
Approved for merge into M56

Comment 15 by, Jan 18 2017

Project Member
Labels: -merge-approved-56 merge-merged-2924
The following revision refers to this bug:

commit 27ebece83822341efae80096834c649ce6822e64
Author: Charles Reis <>
Date: Wed Jan 18 23:56:32 2017

Don't focus the location bar for NTP navigations in non-selected tabs.

BUG= 677716 
TEST=See bug for repro steps.

Cr-Commit-Position: refs/heads/master@{#443338}
(cherry picked from commit 8f3a9a68b2dcdd2c54cf49a41ad34729ab576702)

Review-Url: .
Cr-Commit-Position: refs/branch-heads/2924@{#796}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}


Comment 16 by, Jan 20 2017

Labels: -Hotlist-Merge-Review

Comment 17 by, Jan 23 2017

Labels: -reward-topanel reward-unpaid reward-2000

Comment 18 by, Jan 23 2017

Congratulations! The panel decided to award $2,000 for this bug!  A member of our finance team will be in touch 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.

Comment 19 by, Jan 23 2017

Labels: -reward-unpaid reward-inprocess

Comment 20 by, Jan 24 2017

Labels: Release-0-M56

Comment 21 by, Jan 25 2017

Labels: CVE-2017-5013

Comment 22 by, Apr 21 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 23 by, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment