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.
Prerequisites:
- 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) {
DCHECK(!credentials.account_id.empty());
DCHECK(!credentials.sync_token.empty());
DCHECK(!credentials.scope_set.empty());
- 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.
scheduler_->OnCredentialsUpdated();
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.
VERSION
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
