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


RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

September 2019

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

Top Authors In Last 30 Days

File Tags


packet storm

© 2019 Packet Storm. All rights reserved.

Security Services
Hosting By