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

Issue 321940 link

Starred by 1 user

Issue metadata

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

Issue description

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 ClusterFuzz, 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 ClusterFuzz, 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 ClusterFuzz, 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 ClusterFuzz, 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 ClusterFuzz, 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

it's so dengerous,thank for sharing
https://prediksiangka888.blogspot.com

Labels: CVE_description-submitted

Comment 50 Deleted

Sign in to add a comment