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
OOO July 19-22
Closed: Mar 2011
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 1
Type: Bug-Security

  • Only users with EditIssue permission may comment.

Sign in to add a comment

URL bar spoof

Reported by, Mar 18 2011

Issue description

Test chrome 11.0.696.14 dev windows xp sp3

Comment 1 Deleted

Comment 2 by, Mar 18 2011

Comment 3 by, Mar 18 2011

Works fine on chrome 10.0.648.151

Comment 4 by, Mar 18 2011

Labels: -Pri-0 Pri-1 SecSeverity-High
Status: Untriaged
Confirmed on dev. Didn't have stable handy when I verified.

Comment 5 by, Mar 19 2011

New testcase
stable screen.gif
746 KB View Download
824 bytes Download

Comment 6 by, Mar 21 2011

Labels: Type-Security

Comment 7 by, Mar 22 2011

Cc: a deleted user
Labels: -Area-Undefined Area-WebKit
Summary: URL bar spoof
@mihaip - This looks like another issue with navigation timing. Could you take a look at it?

Comment 8 by, Mar 22 2011

Cc: a deleted user
Are there instructions on how the test case should be run (were they in comment 1, which got deleted?)?

(+Charlie, since he's actually done the most work recently in this area)

Comment 9 by, Mar 22 2011

I just ran the python locally and opened spoof.html from a local webserver on a different port.
Thanks Justin. Here's a simplified version of spoof.htm (the repeated calls are not necessary).
391 bytes View Download

Comment 11 by, Mar 22 2011

Also see bugs  75559  and  75560 , which are probably related.

Comment 12 by, Mar 23 2011

Owner: a deleted user
Status: Started
I think I see what's happening here.  The view-source URL causes us to start a cross-site transition, loading it in a pending RenderViewHost.  When that fails with a 204 error, we aren't cleaning up enough state.  As a result, when the main renderer navigates after the error, RenderViewHost::OnMsgNavigate ignores it because is_waiting_for_unload_ack_ is still true.  Thus, we never call TabContents::DidNavigate and never update the navigation state.

We'll have to do a better job of cleaning up in TabContents::OnDidFailProvisionalLoadWithError.

@lcamtuf, can you CC me on issues  75559  and  75560 ?  I don't have access to them.

Comment 13 by, Mar 23 2011

Not an extensions bug, but adding @aa and @erikkay because it's referenced in an extensions bug.

Comment 16 by, Mar 25 2011

Status: Fixed
Fixed in r79440.
Labels: ReleaseBlock-Stable Mstone-11
Status: WillMerge
Thanks Charlie!!
Since this is marked as High severity, I'll take the liberty of marking it WillMerge for M11. I'll take care of the merge next week, once the change has survived the main waterfall for a bit.

Any thoughts on whether this also resolves @lcamtuf's similar bug?

Comment 18 by, Mar 25 2011

This CL doesn't change when we start displaying the URL, so unfortunately it doesn't help with  issue 75559 .  (The fact that this repro used a view-source: URL was just a convenient way to force a cross-site transition from a renderer-initiated navigation.)

Ditto for  issue 75560 .
Labels: reward-topanel
Status: FixUnreleased
Labels: -Restrict-View-SecurityTeam -reward-topanel Restrict-View-SecurityNotify reward-1000 reward-unpaid
@kuzzcc: nice spoof bug. Repro demonstrates the issue simply enough; accordingly deserves a $1000 Chromium Security Reward. Congrats!

Boilerplate text:
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.
Labels: CVE-2011-1446
Labels: -reward-unpaid
Invoice finalized; payment is in e-payment system; it can take a couple of weeks.
Labels: SecImpacts-Stable
Batch update.
Lifting view restrictions.
Labels: -Restrict-View-SecurityNotify
Lifting view restrictions.
Status: Fixed
Project Member

Comment 28 by, Oct 13 2012

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.
Project Member

Comment 29 by, Mar 10 2013

Labels: -Area-WebKit -SecSeverity-High -Type-Security -Mstone-11 -SecImpacts-Stable Cr-Content Security-Impact-Stable Security-Severity-High M-11 Type-Bug-Security
Project Member

Comment 30 by, Mar 13 2013

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

Comment 31 by, Mar 21 2013

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

Comment 32 by, Mar 21 2013

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

Comment 33 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 34 by, Oct 1 2016

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

For more details visit - Your friendly Sheriffbot
Project Member

Comment 35 by, Oct 2 2016

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

For more details visit - Your friendly Sheriffbot
Labels: allpublic
Labels: CVE_description-submitted

Sign in to add a comment