🤬
  • CVE-2021-38000 Chrome RCA

    Change-Id: I65a516ef89c0710f86de0d0d7dd828986ca54cd8
  • Loading...
  • Maddie Stone committed 2 years ago
    b0d0662a
    1 parent 08fdbf19
  • ■ ■ ■ ■ ■ ■
    0day-RCAs/2021/CVE-2021-38000.md
     1 +# CVE-2021-38000: Chrome Intents Logic Flaw
     2 +*Maddie Stone, Google Project Zero*
     3 + 
     4 +## The Basics
     5 + 
     6 +**Disclosure or Patch Date:** October 28, 2021
     7 + 
     8 +**Product:** Google Chrome
     9 + 
     10 +**Advisory:** https://chromereleases.googleblog.com/2021/10/stable-channel-update-for-desktop_28.html
     11 + 
     12 +**Affected Versions:** pre-95.0.4638.50
     13 + 
     14 +**First Patched Version:** 95.0.4638.50
     15 + 
     16 +**Issue/Bug Report:** https://bugs.chromium.org/p/chromium/issues/detail?id=1249962
     17 + 
     18 +**Patch CL:** https://chromium.googlesource.com/chromium/src/+/36aa9d15d1283d8d9758b044b7a9a20349f507de
     19 + 
     20 +**Bug-Introducing CL:** N/A
     21 + 
     22 +**Reporter(s):** Clement Lecigne, Neel Mehta, and Maddie Stone of Google Threat Analysis Group
     23 + 
     24 +## The Code
     25 + 
     26 +**Proof-of-concept:**
     27 + 
     28 +```
     29 +import SimpleHTTPServer
     30 +import SocketServer
     31 + 
     32 +class FakeRedirect(SimpleHTTPServer.SimpleHTTPRequestHandler):
     33 + def do_GET(self):
     34 + self.send_response(302)
     35 + new_path = '%s%s'%(' intent://google.com#Intent;scheme=https;package=com.mi.globalbrowser;S.browser_fallback_url=yahoo.com;end', self.path)
     36 + self.send_header('Location', new_path)
     37 + self.end_headers()
     38 + 
     39 +SocketServer.TCPServer(("", 8082), FakeRedirect).serve_forever()
     40 +```
     41 + 
     42 +**Exploit sample:**
     43 + 
     44 +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`
     45 + 
     46 +**Did you have access to the exploit sample when doing the analysis?** Yes
     47 + 
     48 +## The Vulnerability
     49 + 
     50 +**Bug class:** Logic/design flaw
     51 + 
     52 +**Vulnerability details:**
     53 + 
     54 +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.
     55 + 
     56 +**Patch analysis:**
     57 + 
     58 +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.
     59 + 
     60 +**Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:**
     61 +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.
     62 + 
     63 +**(Historical/present/future) context of bug:**
     64 + 
     65 +There have previously been vulnerabilities around intent scheme URLs in Android like [this whitepaper](https://www.mbsd.jp/Whitepaper/IntentScheme.pdf) from March 2014 by Takeshi Terada.
     66 + 
     67 +## The Exploit
     68 + 
     69 +(The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).)
     70 + 
     71 +**Exploit strategy (or strategies):**
     72 + 
     73 +Triggering the vulnerability is sufficient for exploitation.
     74 + 
     75 +**Exploit flow:** N/A
     76 + 
     77 +**Known cases of the same exploit flow:** N/A
     78 + 
     79 +**Part of an exploit chain?**
     80 + 
     81 +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.
     82 + 
     83 +## The Next Steps
     84 + 
     85 +### Variant analysis
     86 + 
     87 +**Areas/approach for variant analysis (and why):**
     88 + 
     89 +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.
     90 + 
     91 +**Found variants:** N/A
     92 + 
     93 +### Structural improvements
     94 + 
     95 +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.?
     96 + 
     97 +**Ideas to kill the bug class:** All intents that would transfer execution from an Internet browser app to another application require user consent.
     98 + 
     99 +**Ideas to mitigate the exploit flow:** N/A
     100 + 
     101 +**Other potential improvements:**
     102 + 
     103 +* 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.
     104 + 
     105 +### 0-day detection methods
     106 + 
     107 +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**?
     108 + 
     109 +* Screen browser traffic for intent scheme URLs.
     110 + 
     111 +## Other References
     112 + 
     113 +* 2014: ["Attacking Android browsers via intent scheme URLs"](https://www.mbsd.jp/Whitepaper/IntentScheme.pdf)
     114 +* ["Android Intents with Chrome"](https://developer.chrome.com/docs/multidevice/android/intents/) Chrome documentation
     115 +* ["Create Deep Links to App Content"](https://developer.android.com/training/app-links/deep-linking) Android documentation
     116 +* ["Intents & Intent Filters"](https://developer.android.com/guide/components/intents-filters) Android documentation
     117 + 
Please wait...
Page is in error, reload to recover