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 1 user

Issue 880759: Chrome 69 URL Spoof via double-click

Reported by, Sep 5

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.81 Safari/537.36

Steps to reproduce the problem:
1. step1: click button
2. step2: double click url address bar
3. step3: done

What is the expected behavior?

What went wrong?

        <title>Chrome 69 Double-click URL Spoof - evi1m0.bat[at]</title>
        <li>step1: click button</li>
        <li>step2: double click the address bar of the new window</li>
        <button onclick="pwn()">clickme</button>

            var pwn = () => {
                win ="", "test", "width=400 height=400");
                setTimeout("win.location = './fake_google.html'", 4000);

Did this work before? N/A 

Chrome version: 69.0.3497.81  Channel: stable
OS Version: OS X 10.13.5
Flash Version: 

I think when the page refreshes, URL should be like the result of clicking once, and the address bar will be rendered again.
126 KB View Download

Comment 1 by, Sep 5

Components: UI>Browser>Navigation UI>Browser>Omnibox
Labels: Security_Severity-Medium Security_Impact-Stable
Can somebody confirm this on Mac (doesn't reproduce on ChromeOS or Linux) and suggest an owner?

Comment 2 by, Sep 5

465 KB View Download

Comment 3 by, Sep 5

Duplicated in 69 on Mac. Canary (71.0.3543) works fine. (Shows correct URL.)

Comment 4 by, Sep 5

Project Member
Labels: M-69 Target-69

Comment 5 by, Sep 5


Comment 6 by, Sep 5

Project Member
Labels: -Pri-2 Pri-1

Comment 7 by, Sep 5

Labels: OS-Chrome OS-Linux OS-Windows
Status: Assigned (was: Unconfirmed)
jdonnelly@: This appears to be a regression from the new omnibox refresh in M69, probably related to how the text changes when you click in the omnibox.  If you double click on the omnibox and *then* the page in the tab navigates while the text is selected, we're not resetting the omnibox text to the new URL the way we did in Chrome 68 and before.

Contrary to comments 1 and 3, I can repro this bug on all Chrome 69+ versions/platforms: Windows/Mac/Linux Stable 69.0.3497.81, Mac Canary 71.0.3543.0.

I agree with Medium severity, since it's a URL spoof that has mitigating factors (it depends on the user double clicking at the wrong time).

I expect there's some reset that used to happen in the omnibox logic and doesn't happen anymore.  It is possible to hit Escape to see the new URL, but that didn't used to be necessary, and we should fix that.  Any ideas where to look in the new code?  Thanks!

Comment 8 by, Sep 5

Hmm, that's weird-- I could have sworn I saw it on Mac Canary 71.0.3543.0, but now I can't repro it there (or on Windows Canary).  Maybe this is fixed after all.  I'll try to bisect to see what I come up with.

Comment 9 by, Sep 5

Ah!  I was having trouble bisecting because the bug only occurs when the OmniboxUIExperimentHideSteadyStateUrlSchemeAndSubdomains feature is enabled.  That's enabled by default in Finch, but it doesn't apply to the first run, which is what I was seeing when bisecting (thus I never observed the bug there).

I'm trying again after manually enabling that feature during bisect.  tommycli@, I'm guessing you're familiar with it based on r526096.

Comment 10 by, Sep 5

Status: Fixed (was: Assigned)
Indeed!  This was fixed by tommycli@ in r584056 for  issue 875002 .  Sadly, that landed in 70.0.3526.0 and was not merged to M69.

tommycli@: Would this be a safe merge to M69?

awhalley@: Do you think we should merge it to M69 given the Medium severity?  There's a mitigating factor that the user has to select text in the omnibox to unelide it, but after that the attacker can load any URL they want underneath it without updating the omnibox.

Comment 11 by, Sep 5

It's been in dev for a good couple of weeks, and the fix is nice and straight forward; I'd support a 69 merge.

Comment 12 by, Sep 6

Labels: Merge-Request-69
I support a merge to 69. Merge request for the below patch:

The following revision refers to this bug:

commit 02035ae5926720d49bcd4a1bae42df4ffd6ac158
Author: Tommy C. Li <>
Date: Fri Aug 17 14:14:52 2018

Omnibox: Steady State Elisions - Reset URL unless user has edited it

Currently, if the user has unelided the URL, the URL won't reset on

Instead, we should only only preserve the URL if the user has actually
made modifications, rather than merely uneliding the URL.

Bug:   875002  
Change-Id: Ie138ee9a0b4cf7d7d903d600a739deb2378de29c
Reviewed-by: Justin Donnelly <>
Commit-Queue: Tommy Li <>
Cr-Commit-Position: refs/heads/master@{#584056}

Comment 13 by, Sep 6

Project Member
Labels: -Merge-Request-69 Merge-Review-69 Hotlist-Merge-Review
This bug requires manual review: Request affecting a post-stable build
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit - Your friendly Sheriffbot

Comment 14 by, Sep 6

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

Comment 15 by, Sep 6

Labels: -Merge-Review-69 Merge-Approved-69
Approving merge to M69 branch 3497 based on comments #10,#11 and #12. Please merge ASAP.

Comment 16 by, Sep 6

Comment 17 by, Sep 6

Labels: merge-merged-3497

Comment 18 by, Sep 6

Labels: -Merge-Approved-69 Merge-Merged

Comment 19 by, Sep 6

Thanks all!

Comment 20 by, Sep 7

NextAction: 2018-09-10
tommycli@ to verify on M69 on Monday, 09/10.

Comment 21 by, Sep 7

I've verified that this bug is fixed in the staging build of 69.0.3497.87 on Mac, using --enable-features=OmniboxUIExperimentHideSteadyStateUrlSchemeAndSubdomains.  (As noted in comment 9, that feature is required to see the original bug, and it's enabled by default but not present on the first run in a profile.)

Comment 22 by, Sep 10

The NextAction date has arrived: 2018-09-10

Comment 23 by, Sep 10

Thanks. creis verified in c#21.

Comment 24 by, Sep 11

Labels: reward-topanel

Comment 25 by, Sep 11

Labels: Release-1-M69

Comment 26 by, Sep 12

Labels: -reward-topanel reward-unpaid reward-1000
*** 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 eligible 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 27 by, Sep 12

Nice one evi1m0.bat@! The VRP panel decided to award $1,000 for this report - thanks!

Comment 28 by, Sep 12

Labels: -reward-unpaid reward-inprocess

Comment 29 by, Sep 13

Thank for reward :)

Comment 30 by, Sep 25

Labels: CVE-2018-17459
Pardon the delay. A CVE has has been allocated for this bug, and updated accordingly. Cheers!

Comment 31 by, Sep 25

Labels: CVE_description-missing

Comment 32 by, Dec 13

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 33 by, Jan 4

Labels: -CVE_description-missing CVE_description-submitted

Sign in to add a comment