what you don't know can hurt you

Google Chrome Privilege Escalation

Google Chrome Privilege Escalation
Posted Dec 22, 2016
Authored by Jann Horn, Google Security Research

Google Chrome suffers from a renderer->extension privilege escalation vulnerability via sync.

tags | advisory
MD5 | 34af5609484d280241a49041f9bb0f64

Google Chrome Privilege Escalation

Change Mirror Download
 Google Chrome: renderer->extension privesc via sync 

This bug report shows how an attacker who has compromised a normal renderer process (from a website) can escalate into extension context with lots of permissions.

- the user is signed in
- sync is turned on

First, the attacker needs to obtain an oauth token with scope "<a href="https://www.googleapis.com/auth/chromesync" title="" class="" rel="nofollow">https://www.googleapis.com/auth/chromesync</a>". This can be performed using the following steps on the victim machine:

- navigate to data:text/html,<a href="<a href="https://developers.google.com/oauthplayground/">start" title="" class="" rel="nofollow">https://developers.google.com/oauthplayground/">start</a></a>
- check the PID of the renderer process
- click start
- enter scope "<a href="https://www.googleapis.com/auth/chromesync" title="" class="" rel="nofollow">https://www.googleapis.com/auth/chromesync</a>"
- press "authorize APIs"
- verify that the PID is still the same
- press "allow"
- verify that the PID is still the same
- press "exchange authorization code for tokens"
- copy the access_token

Because the PID didn't change, it is clear that all of these operations have been performed in the original renderer process. Therefore, if the original renderer process has been compromised by the attacker, the attacker can perform all of these steps without user interaction.

The access_token that the attacker has obtained can then be used by the attacker to connect to Chrome's sync server and push arbitrary extensions to the victim machine. To do this, the attacker can build Chrome with a patch that lets the attacker connect to the victim's account using only the victim's email address and the access_token. The attacker patches Chrome as follows (the "XXXXXX" strings are placeholders for the victim's email address and the obtained access_token, you have to replace them with the real values):

diff --git a/components/sync/engine_impl/sync_manager_impl.cc b/components/sync/engine_impl/sync_manager_impl.cc
index 06720a0..be58182 100644
--- a/components/sync/engine_impl/sync_manager_impl.cc
+++ b/components/sync/engine_impl/sync_manager_impl.cc
@@ -495,10 +495,10 @@ void SyncManagerImpl::UpdateCredentials(const SyncCredentials& credentials) {
- cycle_context_->set_account_name(credentials.email);
+ cycle_context_->set_account_name(std::string("XXXXXXXXXX@gmail.com"));

observing_network_connectivity_changes_ = true;
- if (!connection_manager_->SetAuthToken(credentials.sync_token))
+ if (!connection_manager_->SetAuthToken(std::string("ya29.XXXXXXXXXXXXXXXXX")))
return; // Auth token is known to be invalid, so exit early.


The attacker builds Chrome with the patch, runs it *on his own machine* and signs in *with his own credentials*. The attacker's patched Chrome will then synchronize its extension state with the victim's browser, and any extension the attacker installs from the webstore will also be installed in the victim's browser. Permission prompts during extension installation are only shown to the attacker, not the victim.

This demonstrates that, using only a compromised renderer, it is possible to effectively escalate into extension context with more or less all privileges that a normal extension can have.

Chrome Version: 54.0.2840.100 stable
Operating System: Linux

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without a broadly available patch, then the bug report will automatically
become visible to the public.

The Chrome bug is at <a href="https://bugs.chromium.org/p/chromium/issues/detail?id=666284" title="" class="" rel="nofollow">https://bugs.chromium.org/p/chromium/issues/detail?id=666284</a> .

Found by: jannh

Login or Register to add favorites

File Archive:

August 2020

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Aug 1st
    3 Files
  • 2
    Aug 2nd
    2 Files
  • 3
    Aug 3rd
    32 Files
  • 4
    Aug 4th
    22 Files
  • 5
    Aug 5th
    15 Files
  • 6
    Aug 6th
    19 Files
  • 7
    Aug 7th
    6 Files
  • 8
    Aug 8th
    1 Files
  • 9
    Aug 9th
    2 Files
  • 10
    Aug 10th
    27 Files
  • 11
    Aug 11th
    11 Files
  • 12
    Aug 12th
    11 Files
  • 13
    Aug 13th
    0 Files
  • 14
    Aug 14th
    0 Files
  • 15
    Aug 15th
    0 Files
  • 16
    Aug 16th
    0 Files
  • 17
    Aug 17th
    0 Files
  • 18
    Aug 18th
    0 Files
  • 19
    Aug 19th
    0 Files
  • 20
    Aug 20th
    0 Files
  • 21
    Aug 21st
    0 Files
  • 22
    Aug 22nd
    0 Files
  • 23
    Aug 23rd
    0 Files
  • 24
    Aug 24th
    0 Files
  • 25
    Aug 25th
    0 Files
  • 26
    Aug 26th
    0 Files
  • 27
    Aug 27th
    0 Files
  • 28
    Aug 28th
    0 Files
  • 29
    Aug 29th
    0 Files
  • 30
    Aug 30th
    0 Files
  • 31
    Aug 31st
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2020 Packet Storm. All rights reserved.

Security Services
Hosting By