New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 32718 link

Starred by 0 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Jan 2010
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 0
Type: Bug-Security

  • Only users with Commit permission may comment.

Sign in to add a comment

Security: Cross-domain bug in password manager

Reported by, Jan 20 2010

Issue description

I have not had a lot of time to test various scenarios with this issue.  If
you have trouble reproducing, just let me know and I can try to get a more
precise test case.

In messing around with HTTP digest authentication, I discovered a behavior
where the password manager pre-populates the login form for one domain with
the credentials for *another domain*.  It doesn't submit them
automatically, but does leave the user one click away from sending
credentials to the wrong place.

Here are the steps I followed on Chrome under Windows 7 (release

0. Set up an HTML page with the following contents:
     <img src="" />

   This page should be hosted at (not protected by any auth):

1. Next, set up an HTTP digest protected area under the following URL:

2. Now set up the attacker's server to be digest protected, so 
   that the following URL should prompt for digest auth:

3. Log in to a digest-protected area such as:

   Save the password in the password manager.

4. Now, access the unauthenticated HTML page on the victim's server:
   Since the embedded image requires authentication, you should get a
   password prompt.  

The vulnerability I encountered is that the password manager actually
prepopulates's credentials in this dialog.  In message
board websites, or anywhere that an attacker can post links to images on
third party sites, this could be a serious phishing issue.  No other
browser I tested does this.

With digest authentication, this isn't the end of the world since passwords
aren't that easy to get at, but I would be surprised if basic
authentication prompts don't have the same behavior.

I was doing some general security testing on many browsers when I came
across this issue.  I have some additional observations about security
weaknesses in this area which affect many browsers that I'll be publishing
in a week or so.  I will drop a link somewhere here when I get it out and I
hope some of your devs will have a chance to review it.


Thanks for the report.
Wan-Teh, Eric - any thoughts? I haven't had time to look into this.

Regarding your upcoming report, we'd love to get a pre-release version to see if 
there's anything serious we want to tackle before it goes public.
cc:Ian because I believe he's look at some of the previous password manager studies.

Comment 2 by, Jan 21 2010

I don't reproduce this.

I just tested in Chrome, and In both cases for me, in step (4) the 
auth dialog was prompted as expected, however it was *NOT* pre-filled with the 
password from

My tests used Windows Vista, and for the digest realms I used apache webservers.

Comment 3 Deleted

Comment 4 by, Jan 21 2010

Status: Available
Actually I was able to repro this locally now.

The trick is both realms need to be the same.

Comment 5 by, Jan 21 2010

Comment 6 by, Jan 21 2010

OK, great, thanks for trying that again.

Typically we ( release advisories for vulnerabilities like this
once a fix is available.  I don't regard this issue as particularly severe, but it is
a problem that I think should be addressed.

Could you just keep me abreast as to when you think a fix will make it in to a stable

In regard to providing a preview of this research paper: I'm honestly very tempted to
post it here, but since some of the issue listed (minor UI security problems) affect
several browsers, I don't think it would be very fair to provide it only to Chrome
developers.  Since the problems aren't severe (and in fact have been pointed out
before by others), I don't think releasing it without any notice is a problem for end
users.  I do hope to have it posted on our website early next week, so I'll drop a
link here to it at that time.

Thanks again!

Comment 7 by, Jan 21 2010

Ok, so it looks like the problem is in:


76:  TabContents* parent_contents = handler_->GetTabContentsForLogin();
86:  MakeInputForPasswordManager(parent_contents->GetURL(), &v);

So it is using the TAB's URL as the key, rather than the resource's URL.

Inthe GetSignonRealm() function of that same file, it is using this parent URL to form 
the key. Really it should be using |auth_info.host_and_port| to get the authenticating 

Comment 8 by, Jan 21 2010

wtc/eroman: I'm not set up with a repro locally at this point but, do you happen to 
know the values in the AuthChallengeInfo that get presented to CreateLoginPrompt for 
the image resource in this scenario?

Comment 9 by, Jan 21 2010

Oh, well I think that answers my question. Looking at this now.
Thanks Tim (both of you!).

> do you happen to know the values in the AuthChallengeInfo that get presented to
> CreateLoginPrompt for the image resource in this scenario?

Here is the approximate callstack with relevant values:

> chrome.dll!GetSignonRealm(
        auth_info={host_and_port="", scheme="digest"})
        origin_url="", ... )

The main thing is there is a disconnect between the origin of the challenge (""), and the URL which is used for lookups 
(the tab's URL, "").

Comment 11 by, Jan 21 2010

I'm trying to recall why the heck we special case proxy there and use host_and_port in 
that case.  I remember there being a difference, but that was 2 years ago.  Maybe the 
way the AuthChallengeInfo is supplied changed..

Comment 12 by, Jan 22 2010

Status: Fixed
Committed fix in

Comment 13 by, Jan 22 2010

Oh, and thanks Tim & Eric & Wan-Teh for the help!
Labels: NeedsMerge SecSeverity-Medium
Status: FixUnreleased
Tim - the one - for responsibly disclosed vulnerabilities such as 
this, we're delighted to give credit in the form of <name> of <optional affiliation>. 
Let us know what you want us to use. If you could hold off mentioning this until we 
get a patch out, it would be appreciated. I'll have on ETA on the patch early next 

Comment 15 by, Jan 22 2010

scarybeasts:  Yes, don't worry, I won't mention this specific issue until you have a
patch or fixed version available.  In fact, if you like, I can test a release
candidate if you want to verify it's fixed based on my test cases, though I'm sure
you've probably got it under control.  In any case, I won't release an advisory until
the day of or a few days after your fix.  I'll be traveling overseas starting in the
middle of next week, so I'll probably be too busy to write up an advisory right away
anyway. ;-)

As for credit, please associate me (Timothy D. Morgan) with "VSR
(".  While I've released advisories on my personal site in the
past, this work is associated with my company.  Thanks!

Labels: -NeedsMerge
Merged to 249 (r37073) and 249s (r37074).

Comment 17 by, Jan 26 2010

Hi again,

I just published the paper I was working on when I ran across this bug.  Once again,
it doesn't include details about this specific vulnerability. See:

However, it does include details about UI weaknesses and password manager weaknesses
that affect the top 5 browsers.  I will try to find the time over the next few days
to log separate bugs for each major item identified in Chrome.  I'll be trying to
notify all of the browser dev teams though, and I'm flying overseas in 2 days, so I'm
hellishly busy.  Feel free to log separate bugs based on this paper yourselves.

I hope you also take the time to look over the arguments for HTTP authentication and
how I propose to fix it.  In particular, I'd be interested in hearing feedback on my
proposed change to 401 response handling.  I'll be pressuring other browser vendors
to do the same.

Thanks much for the quick response to the initial vulnerability notification.

Comment 18 by, Jan 27 2010

BTW, any ETA on the fix for this issue?
I merged the fix over to our release branch. Something like Tuesday perhaps?

Comment 20 by, Jan 28 2010

Tuesday, February 2nd?  Yeah, that's perfectly fine.  I don't mean to rush you, I
just want to plan my time since I'll be overseas for the next two weeks.  I'll start
getting the advisory put together.
No promises, BTW. There are various dependencies such as QA.
Verified on build, running on Windows Vista.

Comment 23 by, Feb 5 2010

eroman: You mean the fix is verified or the bug still exists on that version?

> eroman: You mean the fix is verified or the bug still exists on that version?

I confirmed that it is fixed in, which is the upcoming version for the stable 

Comment 25 by, Feb 9 2010

Ah, great, thanks!

BTW, I did obtain a CVE number for this issue: CVE-2010-0556

Comment 26 by, Feb 14 2010

Hello again.  I see that version has been released.  I've drafted an
advisory which is available here:

(It's not publicly linked to yet.)  

I plan on announcing this tomorrow afternoon (US Pacific time) unless anyone has any
objections.  Let me know if you notice any inaccuracies in the document. Thanks.
Labels: -Restrict-View-SecurityTeam
Status: Fixed
Labels: Reward-500
Labels: Type-Security
Labels: SecImpacts-Stable
Batch update.
Fix may cause regression -  Issue #107009 
Project Member

Comment 32 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.
Labels: reward-decline
Project Member

Comment 34 by, Mar 10 2013

Labels: -SecSeverity-Medium -Type-Security -SecImpacts-Stable Security-Impact-Stable Security-Severity-Medium Type-Bug-Security
Project Member

Comment 35 by, Mar 11 2013

Labels: -Area-Undefined
Project Member

Comment 36 by, Mar 21 2013

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

Comment 37 by, Mar 21 2013

Labels: -Security-Severity-Medium Security_Severity-Medium
Labels: allpublic

Sign in to add a comment