Maddie Stone, Google Project Zero
Disclosure or Patch Date: October 28, 2021
Product: Google Chrome
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
Bug-Introducing CL: N/A
Reporter(s): Clement Lecigne, Neel Mehta, and Maddie Stone of Google Threat Analysis Group
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()
A 302 redirect with the destination URL of:
Did you have access to the exploit sample when doing the analysis? Yes
Bug class: Logic/design flaw
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.
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 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
Areas/approach for variant analysis (and why):
- 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
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.
- 2014: "Attacking Android browsers via intent scheme URLs"
- "Android Intents with Chrome" Chrome documentation
- "Create Deep Links to App Content" Android documentation
- "Intents & Intent Filters" Android documentation