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 metadata

Status: Fixed
OOO until Feb 11
Closed: Oct 2011
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Issue 88949: Security: Location Bar Spoofing using very long string on a web address in the location bar

Reported by, Jul 11 2011

Issue description

When a webpage try to go on a website that contain very long string in the address location , location bar is spoofed (view screenshot).

Chrome Version: [14.0.794.0] + [stable, beta, or dev]
Operating System: [Windows 7]

view Testcase1 and Tescase2

/Jordi Chancel
45.7 KB View Download
1004 KB View Download
329 bytes View Download

Comment 1 by, Jul 12 2011

Labels: -Pri-0 -Area-Undefined Pri-1 Area-UI SecSeverity-Medium Mstone-13 OS-All
Status: Assigned
Charlie, can you add this to your url bar spoofing bugs :)

Jordi, do you have any repro that does not need drag interaction. That will increase the secseverity.

Comment 2 by, Jul 12 2011

I will try to code a perfect testcase soon.

Comment 3 by, Jul 24 2011

I think that it's possible to automate this without drag interaction but i haven't found a way for that (except TESTCASE2).

SecSeverity-Medium is probably appropriate but not sure.

Can you try to find a way for this ? 


Comment 4 by, Jul 29 2011

someone can help me to found a repro without drag interaction? thanks

Comment 5 by, Aug 29 2011

@creis , I don't found a way for automate this, except TestCase2.html but I think that it's possible. 

Assigned for Google Chrome 13.x.x.x?

Comment 6 by, Sep 7 2011


Comment 7 by, Sep 17 2011

@creis : Why nobody works on this vulnerability?

Comment 8 by, Sep 28 2011

Labels: -Mstone-13 Mstone-14

Comment 9 by, Sep 28 2011

Sorry, I've been out of town for a bit.  I'll take a look at this one tomorrow to see if I can figure it out.

Comment 10 by, Sep 29 2011

Status: Started
Karl and I are taking a look.  The dragging of the long text to the URL bar initiates a search, and the fact that it's really long is breaking something in Chrome so that the spoof occurs.

Interesting observations:
1) If you copy a smaller portion of the text from the test page, Chrome will take you to Google but you'll see a 414 error page because the search string is too long.
2) If you change your search provider, the spoof will affect the new search engine instead of

There seem to be two issues involved.  First, the renderer is unable to parse the ViewMsg_Navigate IPC message with the long URL, so it drops it on the floor.  This is why the old content stays in the tab.  (Interestingly, in a debug build we actually end up with a sad tab, but release builds just ignore the IPC message.)

Second, the browser is confusingly showing "" in the Omnibox rather than the full search string (something like "").  We'll have to figure out why that's the case.

I think we should fix both issues-- the browser shouldn't be sending the renderer a message it can't decode, and we shouldn't be showing the wrong search URL while waiting for the search to complete.

Comment 11 by, Sep 29 2011

Chris, it appears that the second issue I described in comment 10 is intentional from your change here:

We're apparently cropping overly-long URLs to just the origin, rather than eliding them.  I don't see much of a better option, so perhaps we should just keep that behavior as is?

If so, dragging a long URL into the omnibox may end up taking you to a search results page (or a 414 error page) where the URL bar just shows (or whatever your search provider's origin is).  I suppose that's ok, from a URL spoof perspective.

We'll look at the failed IPC message parsing next.  I'm guessing the browser will have to catch this case before sending the message and abort the navigation instead, so that we don't show it in the URL bar.

Comment 12 by, Sep 29 2011

Interestingly, the IPC message parse is failing due to a similar check that Chris added to protect the browser from OOM ( issue 20233 ):

That CL causes us to avoid parsing any URL over size kMaxURLChars.  If the user types or drags a longer URL to the location bar (as in this bug), the renderer rejects it, either ignoring it or crashing in a debug build.

Conversely, if a longer URL shows up as a link in a web page and the renderer tries to put it in a message to the browser (e.g., by hovering over the link or clicking it), the browser process crashes in debug builds (yikes!).  In release builds, the browser process kills the renderer with a "He's dead, Jim," presumably because of the bad message.

That's no good.  We could easily add a check in TabContents::NavigateToEntry to avoid trying to navigate to a really long URL, but that's only part of the problem.  There's still plenty of ways URLs can end up in IPC messages, and we don't have guards against long URLs for any of them.  As a result, a page that gets long URLs sent to the browser process can easily cause crashes.  (Case in point, see  issue 71691 .)

Chris, I'm wondering if we should revisit how the kMaxURLChars check is done...  Should we have a check on the send side so that we don't send messages from the browser that the renderer can't receive?  Should we have guards on all the places that try to send messages with URLs so that they can handle the failure?  (There could be a lot of those...)  Any other ideas for avoiding these crashes?

Comment 13 by, Sep 30 2011

Yes, we can have the check on the send side if we wish. It's an explicit non-goal to defend the browser process against DoS from a compromised renderer.

The concern leading to the "kill process and tab" implementation was: what to do if we want to reject a web page's attempt to set e.g. document.location? A lot of security decisions key off document.location so we were a little nervous on how to reject changes without leading to an inconsistent state.

Comment 14 by, Sep 30 2011

Here's what I'm thinking.  Perhaps we should allow the browser to keep killing renderers if they send messages with long URLs, since it's not that different from a renderer dying from OOM.  (It seems impractical to add guards for every way the renderer could send a URL to the browser, anyway.)

However, we should probably be careful not to send IPC messages from the browser to the renderer that we know will fail to parse.  We'll start by adding a guard on the Navigate message to fix this spoof, but we should look at other ways the browser sends URLs to the renderer to see if we can add guards there as well.  Otherwise we knowingly put ourselves into an odd state.

Comment 15 by, Sep 30 2011

I've gone through content/common/view_messages.h, and these are the other ViewMsgs that can send URLs to the renderer:


These either seem safe to drop, pass constants, or send the URL that the browser is already at (meaning that if you can't navigate to an excessively-long URL, these will never send an excessively-long URL).

Comment 16 by, Oct 3 2011

Project Member
The following revision refers to this bug:

r103720 | | Mon Oct 03 09:19:40 PDT 2011

Changed paths:

Add a check to NavigateToEntry to make sure the browser never attempts to navigate to a URL longer than content::kMaxURLChars

Patch from Karl Koscher <>
BUG= 88949 

Review URL:
Patch from Karl Koscher <>.

Comment 17 by, Oct 3 2011

Status: Fixed
Fixed in r103720.  Chris, shall we merge this to the release branches?

Comment 18 by, Oct 3 2011

Labels: Merge-Approved
Status: FixUnreleased

Comment 19 by, Oct 4 2011

Labels: -Restrict-View-SecurityTeam -Mstone-14 Restrict-View-SecurityNotify Mstone-15 reward-topanel
Heya Charlie, quick question for the curious: any reason the renderer doesn't kill itself if it fails to deserialize a message? Seems like we're pretty much in an awful state if that happens, so sad-tabbing is the safest thing to do. And indeed would have saved us this bug (at least the security aspect)?

In terms of merging, there's just M15 open. We'll merge it for you if you like.

Comment 20 by, Oct 4 2011

That's not a bad idea-- Karl listed the other ways that an unreadable message might get sent to the renderer in comment 15, and those mostly seem like things that would be prevented by not being able to navigate to an excessively long URL.  Having the renderer kill itself might be a good second line of defense.

Do you know the right approach to do that from within the renderer process?  In the browser process we use BrowserRenderProcessHost::ReceivedBadMessage with a UMA stat so that we can track it, though this doesn't generate a crash dump.  Would be nice to be able to track if this sort of kill happens frequently (or at all).

Comment 21 by, Oct 4 2011

Also, I just confirmed that the fix does prevent the spoof on the Mac canary, 16.0.900.0.  Feel free to merge it to M15!

Comment 22 by, Oct 4 2011

Wouldn't the best solution be to just use a hard CHECK in the renderer? That way we'd have a crash report to work from in tracking these down?

Comment 23 by, Oct 4 2011

Project Member
The following revision refers to this bug:

r104010 | | Tue Oct 04 15:55:40 PDT 2011

Changed paths:

Add a second line of defense for receiving a bad message in the renderer.

BUG= 88949 

Review URL:

Comment 24 by, Oct 5 2011

Labels: SecImpacts-Stable
Batch update: Guessing based on search criteria that this security bug impacted a stable release.

Comment 25 by, Oct 7 2011

Charlie, can you please merge this to 874 branch.

Comment 26 by, Oct 7 2011

Sure, will do.

Comment 27 by, Oct 7 2011

Drat, the patches fail to compile on the 874 branch, since the test relies on a newer version of NavigationController::LoadURL.  Once the builders go green, I'll try to merge again, omitting the test.

Comment 28 by, Oct 7 2011

Merged to the 874 branch in r104552 and r104554 (minus the test).

Comment 29 by, Oct 8 2011

Labels: -Merge-Approved Merge-Merged merge-merged-874
Thanks a lot Charlie.

Comment 30 by, Oct 12 2011

chrome 15.0.874.92 BETA fixes this vulnerability(TESTCASE1.HTM).

Comment 31 by, Oct 19 2011

Labels: -reward-topanel
A drag interaction leading to an URL spoof seems like a fairly minor risk.

Comment 32 by, Oct 19 2011

Labels: CVE-2011-3875

Comment 33 by, Oct 22 2011

@scarybeast : can i write a blog post about this vulnerability now ?

Comment 34 by, Oct 23 2011

@scarybeast : I go write an post blog about this vulnerability without PoC...
Let me know if you want the deletion of this post !

Comment 35 by, Oct 24 2011

@jordi: if you just wait a day or two, you can blog about it _and_ link to the fixed stable build. That is preferable all round.
Keep an eye out on over the next couple of days :D

Comment 36 by, May 15 2012

Status: Fixed
Marking old security bugs Fixed..

Comment 37 by, Oct 13 2012

Project Member
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

Comment 38 by, Mar 10 2013

Project Member
Labels: -Type-Security -Area-UI -SecSeverity-Medium -Mstone-15 -SecImpacts-Stable M-15 Security-Severity-Medium Cr-UI Security-Impact-Stable Type-Bug-Security

Comment 39 by, Mar 13 2013

Project Member
Labels: Restrict-View-EditIssue

Comment 40 by, Mar 13 2013

Project Member
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Comment 41 by, Mar 21 2013

Labels: -Restrict-View-SecurityNotify -Restrict-View-EditIssue

Comment 42 by, Mar 21 2013

Project Member
Labels: -Security-Impact-Stable Security_Impact-Stable

Comment 43 by, Mar 21 2013

Project Member
Labels: -Security-Severity-Medium Security_Severity-Medium

Comment 44 by, Apr 4 2014

Labels: -Security_Severity-Medium Security_Severity-None
This was incorrectly rated. Fixing severity. Drag interaction on location bar is a significant user interaction and we don't expect users to fall through this trap.

Comment 45 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 46 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 47 by, Oct 2 2016

Labels: allpublic

Comment 48 by, Apr 26 2018

Labels: CVE_description-submitted

Sign in to add a comment