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: Oct 2013
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

Sign in to add a comment

Issue 281256: Address bar spoofing with + 204 No Content

Reported by, Aug 29 2013

Issue description

UserAgent: Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.62 Safari/537.36

Steps to reproduce the problem:
1. Go to attached PoC.
2. Click go button.
3. You can see in address bar. But it is incorrect.

What is the expected behavior?
Chrome should point URL correctly.

What went wrong?
Chrome points incorrect URL.

Did this work before? N/A 

Chrome version: 29.0.1547.62  Channel: stable
OS Version: 6.2 (Windows 8)
Flash Version: Shockwave Flash 11.8 r800

Comment 1 by, Aug 29 2013

PoC is here:
9.4 KB View Download

Comment 2 by, Aug 29 2013

Status: Untriaged
It looks like prompts for the previous page are getting fired after we update the omnibox. This may have been introduced after we changed these modal dialogs into constrained dialogs.

@creis - Any thoughts on who I can point at this?

Comment 3 by, Aug 29 2013

Labels: -Pri-2 -OS-Windows Pri-1 OS-All M-29 Cr-UI-Browser-Navigation
Status: Assigned
I'll take a look along with the other spoof bug.  Likely fallout from  issue 9682 .

Comment 4 by, Aug 29 2013

Ah, nice.  We normally detect any access to the initial empty document and report it to the browser process so that we can prevent spoofs like this.  (That was implemented in

However, we do the notification in a one-shot timer, which means it doesn't arrive until after the modal JavaScript dialogs in this attack have been shown to the user under the spoofed URL.

I can block this by calling DidAccessInitialDocument in the browser process if it tries to show a JavaScript dialog, though that may not cover 100% of the ways an attacker could put off the notification.  One alternative would be making the notification without using a timer.  Adam, you argued against that in comment 18 of  Do you think we should stick with the timer and just try to catch cases like this in the browser process?

Comment 5 by, Sep 3 2013

Labels: Security_Impact-Stable Security_Impact-Beta
Fix labels.

Comment 6 by, Sep 3 2013

Labels: Security_Severity-High reward-topanel

Comment 7 by, Sep 4 2013

Status: Started
We have a plausible patch in progress here:

Comment 8 by, Sep 4 2013

Project Member

Comment 9 by, Sep 4 2013

Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify Merge-Approved
Status: Fixed

Comment 10 by, Sep 4 2013

I'll wait to merge this to M30 and M29 until it bakes on tomorrow's canary for a bit, but it does affect both of those branches.

Comment 11 by, Sep 9 2013

Ok, this has been baking since 31.0.1622.0.  It seems to prevent the attack and I don't see any fallout in the crash logs.  I'll plan to merge it to M30 and then M29 if that's ok.

Comment 12 by, Sep 9 2013

Just M30 is probably ok, if it limits the work / risk :)

Comment 13 by, Sep 10 2013

Labels: -M-29 M-30
Ok, I'll stick with that unless I hear otherwise.

Comment 14 by, Sep 10 2013

Project Member
Labels: -Merge-Approved merge-merged-1599
The following revision refers to this bug:

r157486 | | 2013-09-10T00:07:58.064630Z

Changed paths:

Merge 157196 "Don't wait to notify client of spoof attempt if a ..."

> Don't wait to notify client of spoof attempt if a modal dialog is created.
> BUG= 281256 
> TEST=See bug for repro steps.
> Review URL:

Review URL:

Comment 15 by, Sep 12 2013

Labels: Release-0

Comment 16 by, Sep 16 2013

Labels: Merge-Merged

Comment 17 by, Sep 25 2013

Did you saw our new criteria for possibly issuing higher rewards? See
E.g. If you are able to provide a repro that faulted at an address of 0x41414141, it will qualify for the new higher rewards. Or, if you can show that you have control between free and crash points, etc.

Comment 18 by, Sep 26 2013

Labels: CVE-2013-2908

Comment 19 by, Sep 27 2013

Labels: -CVE-2013-2908 CVE-2013-2917

Comment 20 by, Sep 27 2013

Labels: -CVE-2013-2917 CVE-2013-2916

Comment 21 by, Sep 28 2013

Labels: -reward-topanel reward-2000 reward-unpaid
Nice spoof & repro. $2000

Comment 22 by, Oct 4 2013

Latest Chrome for android (30.0.1599.82) still has similar issue.
I attached PoC. This case can spoof without using modal dialog.
Should I report it as new issue?
9.6 KB View Download

Comment 23 by, Oct 4 2013

Status: Started
Confirmed.  The original repro case appears to work on Android as well (and I expect several other recent spoofs are possible).  It's harder for me to verify, but I suspect that NotifyNavigationStateChanged(content::INVALIDATE_TYPE_URL) is not causing the omnibox to refresh its URL on Android, since that's what we're using in didAccessInitialDocument.

@inferno, I'll reopen this for the time being, but let me know if it's better to file a separate bug for the Android behavior.

Comment 24 by, Oct 4 2013

we should file a seperate bug, since reward handling, merging, etc will be easier to track.

Comment 25 by, Oct 4 2013

Status: Fixed
Thanks.  Filed  issue 304226 , which we can attribute to masatokinugawa.

Comment 26 by, Oct 18 2013

Labels: -reward-unpaid reward-inprocess
I just kicked off payment via e-payment system, which can take a few weeks, but reward should be on its way to you. Thanks again for your help!

Comment 27 by ClusterFuzz, Feb 6 2014

Project Member
Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.

Comment 28 by, Feb 28 2014

Labels: -reward-inprocess

Comment 29 by ClusterFuzz, Feb 2 2016

Project Member
Labels: -Security_Impact-Beta

Comment 30 by, Oct 1 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 31 by, Oct 2 2016

Project Member
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit - Your friendly Sheriffbot

Comment 32 by, Oct 2 2016

Labels: allpublic

Comment 33 by, Apr 25 2018

Labels: CVE_description-submitted

Sign in to add a comment