Project: chromium Issues People Development process History Sign in
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
Status: Fixed
Owner:
Email to this user bounced
Closed: Dec 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug-Security



Sign in to add a comment
Security: Inserting a Google account to Chrome and stealing user's private data
Reported by jaumlu...@gmail.com, Nov 21 2013 Back to list
VULNERABILITY DETAILS
An attacker can send a malicious URL to a victim and insert his account to her Google Chrome to sync the victim's private data (history, passwords, etc.) without the victim's knowledge.

VERSION
Chrome Version: [31.0.1650.57] + [stable]
Operating System: MAC OS X 10.8.5

REPRODUCTION CASE
I attached a simple PoC in PHP.

Change the email and password vars (any Google email and password under your control) and, if needed, change the millisecondsToReplaceWindow.

Sometimes the PoC does not work in the first time because some Google accounts will ask you to add the account to Chrome direct from the Web UI, in that cases you need click on "Skip for now" and reproduce the PoC again (change the millisecondsToReplaceWindow to 60000, click on 'Start the hack!' and click on 'Skip for now'. After change the millisecondsToReplaceWindow to the original value, sign out of the account in the Chrome settings and try again).

This PoC was tested in Chrome instances without other accounts linked, please create a new user if you already have an account linked to your Chrome (just disconnect your account will not solve the problem and the PoC may not work).

FIX
You need ask the Chrome users if they really want to add an Google account to their Chrome BEFORE actually add the account, with an dialog that attackers can not control or close.
 
Comment 1 by jaumlu...@gmail.com, Nov 21 2013
PoC attached.
Chromiumsync_hack.txt
3.5 KB View Download
Comment 2 by jsc...@chromium.org, Nov 21 2013
Labels: Cr-Services-Sync Cr-Services-SignIn
Adding labels so someone so sync and sign-in can take a look.
Owner: guohui@chromium.org
Quick look says it signs in and then closes the confirmation (presumably with the "undo" link) before it is seen.

source=5 is a webstore thing.  Assigning to Hui as she worked on that.
Looking at the php file, the attacker uses /ClientLogin and /IssueAuthToken to mint an uber auth token for a google account they control.  They use this uber auth token with /MergeSession to stuff the cookie jar with credentials of that google account.  Note that this only works if the user is not already signed in to a google account in the content area.  They would have to log out the content area first and then do the merge session, similar to what is already described in 307159.

When the attacker calls /MergeSession, it uses unneeded URL parameters like source=chromiumsync and continue=<chrome-signin-continue-url> to make chrome think this is an attempt to sign in to chrome.  Since all this happens with real gaia URLs and with a valid account/password, chrome accepts this and connects the profile.

Note sure why source=5 is needed.  Needs more investigation.

Comment 5 by jsc...@chromium.org, Nov 21 2013
Labels: Security_Severity-Medium reward-topanel Pri-1 OS-All Cr-Webstore M-32
Project Member Comment 6 by clusterf...@chromium.org, Nov 21 2013
Labels: Security_Impact-Beta
Fixing impact labels.
Comment 7 by guohui@chromium.org, Nov 21 2013
This is not a webstore specific issue, i was able to repro it for source=2 on local computer with a slightly modified script. Also by adding &sarp=1 to the mergeSession url, an attacker could suppress the Chrome signin promo page thus always succeed, even for the first time.

there are at least two issues here.

first when the untrusted signin confirmation dialog is closed without clicking 'ok, got it', e.g., by clicking the cross icon on the top right corner, or by closing the associated window as in the reported case, Chrome starts sync with default settings instead of canceling the pending signin.

Second, OneClickSigninHelper treats any non-gaia url with a google-account-signin header and a request param of source as an attempt to sign in to chrome. This is only guarded by the untrusted signin confirmation dialog, which in the reported case failed.

A simple fix is to cancel signin when the untrursted confirm dialog is closed without clicking 'ok got it'.  We should also improve our detection of chrome signin attempt, but given the current signin flow will soon be replaced by native inline UI, and the issue would no longer apply, i think we may just implement the simple fix for now.


Comment 8 by guohui@chromium.org, Nov 21 2013
Status: Started
Project Member Comment 9 by clusterf...@chromium.org, Nov 21 2013
Labels: ReleaseBlock-Stable
Labels: -ReleaseBlock-Stable
Medium Severity Bugs should not need this label. This is only for high+ severity bugs.
Cc: rpop@chromium.org
Correction to Hui second point in comment #7:  this comment really refers to  bug 307159 .
Project Member Comment 13 by bugdroid1@chromium.org, Nov 25 2013
------------------------------------------------------------------------
r237115 | guohui@chromium.org | 2013-11-25T19:12:18.336520Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/one_click_signin_view_controller.mm?r1=237115&r2=237114&pathrev=237115
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/one_click_signin_dialog_controller_browsertest.mm?r1=237115&r2=237114&pathrev=237115
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/sync/one_click_signin_bubble_view_unittest.cc?r1=237115&r2=237114&pathrev=237115
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc?r1=237115&r2=237114&pathrev=237115

Security fix for untrusted signin confirm dialog

When the window associated with the confirm dialog is closed without user clicking 'ok got it', chrome starts sync with default settings. This could be exploited to sign a user's Chrome into an attacker's account, as reported in crbug 321940.

BUG= 321940 

Review URL: https://codereview.chromium.org/79553004
------------------------------------------------------------------------
should we merge the fix to beta?
Labels: ReleaseBlock-Stable
We should probably verify it's working in this week's Dev channel, and then merge.

+release-block label for any TPM guidance in the meantime.
Project Member Comment 16 by clusterf...@chromium.org, Nov 26 2013
Labels: M-31 Security_Impact-Stable
Labels: -M-31 -Security_Impact-Stable
Comment 18 by kareng@google.com, Dec 2 2013
Labels: Merge-Approved
Project Member Comment 19 by bugdroid1@chromium.org, Dec 2 2013
Labels: -Merge-Approved merge-merged-1700
------------------------------------------------------------------------
r238138 | rogerta@chromium.org | 2013-12-02T18:44:03.169153Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/chrome/browser/ui/cocoa/one_click_signin_dialog_controller_browsertest.mm?r1=238138&r2=238137&pathrev=238138
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/chrome/browser/ui/views/sync/one_click_signin_bubble_view_unittest.cc?r1=238138&r2=238137&pathrev=238138
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/chrome/browser/ui/views/sync/one_click_signin_bubble_view.cc?r1=238138&r2=238137&pathrev=238138
   M http://src.chromium.org/viewvc/chrome/branches/1700/src/chrome/browser/ui/cocoa/one_click_signin_view_controller.mm?r1=238138&r2=238137&pathrev=238138

Merge 237115 "Security fix for untrusted signin confirm dialog"

> Security fix for untrusted signin confirm dialog
> 
> When the window associated with the confirm dialog is closed without user clicking 'ok got it', chrome starts sync with default settings. This could be exploited to sign a user's Chrome into an attacker's account, as reported in crbug 321940.
> 
> BUG= 321940 
> 
> Review URL: https://codereview.chromium.org/79553004

TBR=guohui@chromium.org

Review URL: https://codereview.chromium.org/99343006
------------------------------------------------------------------------
Comment 20 by kareng@google.com, Dec 2 2013
can i close this roger?
Status: Fixed
Project Member Comment 22 by clusterf...@chromium.org, Dec 2 2013
Labels: -Restrict-View-SecurityTeam Restrict-View-SecurityNotify
Hey guys,

Thanks for the quickly fix.

Any news of the security panel?

Cheers,
Joao Lucas Melo Brasio.
Labels: Release-0-M32
Labels: CVE-2013-6643
Just a note.

The Google Sign In XSRF used here was reported to Google Security Team in the report [#8-7172000002294].

Thanks.
One doubt.

Why the  bug 252062  was classified with Pri-0 and Security_Severity-High and this bug with Pri-1 and Security_Severity-Medium?

What is the difference about these bugs?

Is not all about Chrome Sync?

Thanks.
Labels: -Security_Severity-Medium -reward-topanel Security_Severity-High reward-unpaid reward-5000
Thanks for the report! It qualifies for a $5000 reward. This was a particularly nasty bug, as it could have allowed an attacker to sync extensions of his or her choice to a victim's browser.

As for your concern in comment #27, this should have been marked as high severity. I've updated it accordingly.
Thank you guys.

=)
Labels: -Release-0-M32
Comment 31 Deleted
Please do not release this bug before the fix for the Google Sign In XSRF used in this exploit.
Labels: -reward-unpaid reward-inprocess
Hey Joao,

I've moved across from the Web reward program to the Chrome one. Good to know that I'll still get to work with you over here!

As you certainly know, processing via the e-payment system can take a few weeks, but reward should be on its way to you. Thanks again for your help!

Cheers,
Tim

Hey Tim,

How are you doing?

I am glad because I will have someone I know in Chromium Security Team to work with me.
=)

Ok, I can wait, thank you guys again.

Cheers,
Joao Lucas.
Project Member Comment 35 by clusterf...@chromium.org, Mar 28 2014
Labels: -Restrict-View-SecurityNotify
Bulk update: removing view restriction from closed bugs.
Hey Joao - can you confirm if you've received this payment yet?
Actually, Finance tells me that payment is due around 29 April, so I answered my own question :)
That script is what ya kak? Please explain to me, because I wanted depth. and want to learn



http://www.sewuanblog.tk/2016/01/cara-membuat-plugin-comment-facebook-di.html
Thanks for your greeting. i have see your profile blog, i very like with your page. but i need much more about your article smile
because your article is so so nice.


http://daftarcaramembuatakunemail.blogspot.com
Comment 40 Deleted
This could be dangerous attacker will know your Google account password, Thanks for sharing. 
http://caramembuatmengatasiakun.blogspot.com
Comment 42 Deleted
should we merge the fix to beta? http://wfdshare.com
Project Member Comment 44 by sheriffbot@chromium.org, Oct 1 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member Comment 45 by sheriffbot@chromium.org, Oct 2 2016
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Labels: allpublic
Comment 47 Deleted
Sign in to add a comment