STRLCPY/0days-in-the-wild

CVE-2020-6572 Chrome MediaCodecAudioDecoder RCA

Change-Id: Ic7cf2a8ebd0aca975f2b3d16ab4982ef6e10d388

Ben Hawkes committed 3 years ago

42ace3da

1 parent 8ba202aa

Total 1 files

■ ■ ■ ■ ■ ■

0day-RCAs/2020/CVE-2020-6572.md

1	+	# CVE-2020-6572: Chrome MediaCodecAudioDecoder Sandbox Escape
2	+	Ben Hawkes, Project Zero
3	+
4	+	## The Basics
5	+
6	+	Disclosure or Patch Date: 7 April 2020
7	+
8	+	Product: Google Chrome
9	+
10	+	Advisory: https://chromereleases.googleblog.com/2020/04/stable-channel-update-for-desktop_7.html
11	+
12	+	Affected Versions: pre 81.0.4044.92
13	+
14	+	First Patched Version: 81.0.4044.92
15	+
16	+	Issue/Bug Report: https://bugs.chromium.org/p/chromium/issues/detail?id=1066893
17	+
18	+	Patch CL: https://chromium.googlesource.com/chromium/src.git/+/c0268599d1161f4c57a7911c7f036f70af88c8d0
19	+
20	+	Bug-Introducing CL: https://source.chromium.org/chromium/chromium/src/+/2864f6e586bc2eba6b7479fee7738a0a2779dd0f (Commited on 2016-03-23)
21	+
22	+	Reporter(s): Anonymous
23	+
24	+	## The Code
25	+
26	+	Proof-of-concept: N/A
27	+
28	+	Exploit sample: N/A
29	+
30	+	Did you have access to the exploit sample when doing the analysis? No
31	+
32	+	## The Vulnerability
33	+
34	+	Bug class: Use-after-free
35	+
36	+	Vulnerability details:
37	+
38	+	The vulnerability is that `MediaCodecAudioDecoder::Initialize` doesn't reset `media_crypto_context_` if `media_crypto_` has been previously set. This can occur if `MediaCodecAudioDecoder::Initialize` is called twice, which is explicitly supported. This is problematic when the second initialization uses a different Content Decryption Module (CDM) than the first one. Each CDM owns the `media_crypto_context_` object, and the CDM itself is reference counted. Once the new CDM is set, the old CDM loses a reference and may be destructed. However, `MediaCodecAudioDecoder` still holds a raw pointer to `media_crypto_context_` from the old CDM since it wasn't updated, which results in a UAF on `media_crypto_context_` (for example, in `MediaCodecAudioDecoder::~MediaCodecAudioDecoder`).
39	+
40	+	In the most abstract sense, the problem arises when one `unique_ptr` is assigned to another. Assignment makes the original `unique_ptr` go out of scope, meaning it can be deleted. At the same time a raw pointer from the originally referenced object isn't updated.
41	+
42	+	Patch analysis:
43	+
44	+	The patch ensures that double-initialization of the decoder service can't change the CDM. This means that the CDM won't be destructed, and so `media_crypto_context_` won't be left dangling.
45	+
46	+	Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:
47	+
48	+	It's most likely that this issue was found through manual review, particularly by studying past issues in this area. It could also have been found statically (e.g. using CodeQL). Fuzzing is possible, but would necessarily have been carried out on a build that supported CDM instantiation (e.g. Widevine support).
49	+
50	+	(Historical/present/future) context of bug:
51	+
52	+	* April 2020: This vulnerability was reported as exploited in-the-wild.
53	+	* September 2019: Man Yue Mo of Semmle [reported a very similar vulnerability](https://bugs.chromium.org/p/chromium/issues/detail?id=1004730), [CVE-2019-13695](https://chromereleases.googleblog.com/2019/10/stable-channel-update-for-desktop.html).
54	+	+ This vulnerability is essentially the same bug as CVE-2020-6572, it's just triggered by an error path after initialize `MojoAudioDecoderService` twice rather than by re-initializing `MediaCodecAudioDecoder`.
55	+	* August 2019: Guang Gong of Alpha Team, Qihoo 360 [reported a similar vulnerability](https://bugs.chromium.org/p/chromium/issues/detail?id=999311) in the same component, [CVE-2019-5870](https://chromereleases.googleblog.com/2019/09/stable-channel-update-for-desktop.html).
56	+
57	+	## The Exploit
58	+
59	+	(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).)
60	+
61	+	We did not see a copy of the exploit and thus don't know anything about the exploit method.
62	+
63	+	Exploit strategy (or strategies):
64	+
65	+	Exploit flow:
66	+
67	+	Known cases of the same exploit flow:
68	+
69	+	Part of an exploit chain?
70	+
71	+	While we don't know for sure, this vulnerability is specifically in the Chrome implementation for Android so it's like that this vulnerability was chained with a Chrome renderer exploit and an Android GPU exploit.
72	+
73	+	## The Next Steps
74	+
75	+	### Variant analysis
76	+
77	+	Areas/approach for variant analysis (and why):
78	+
79	+	* Checked that there are no other instances of `cdm_context_ref_` being reassigned. Looks good.
80	+	* Checked related service endpoints for problems with multiple calls to Initialize or similar routines. Most other Initialize routines can only be called once. Decryptor can be called multiple times, but no dangling pointers to be found.
81	+	* Checked for other instances of `scoped_refptr`'s being assigned to in the same area. Nothing else that looks interesting.
82	+	* Generation of `cdm_id` can wrap (incrementing 32-bit integer). Might lead to problems in `MojoCdmService::~MojoCdmService()` -- however it's not very practical, this would take 14+ days on a Pixel 3a.
83	+
84	+	Found variants:
85	+
86	+	While not a variant, analyzing this vulnerability led to more analysis of Android GPU vulnerabilities. This led to CVE-2020-11179 in Qualcomm's Adreno GPU. [blogpost](https://googleprojectzero.blogspot.com/2020/09/attacking-qualcomm-adreno-gpu.html)
87	+
88	+	### Structural improvements
89	+
90	+	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.?
91	+
92	+	Ideas to kill the bug class:
93	+	Allocator-assisted pointer safety designs like MiraclePtr would likely apply to bugs like this.
94	+
95	+	Eventually memory-tagging in Chrome's browser/GPU process would potentially make issues like this unexploitable, but hardware isn't generally available as of publication, and important implementation details are still uncertain (for example, regarding synchronous vs asynchronous detection of violations).
96	+
97	+	Ideas to mitigate the exploit flow: N/A
98	+
99	+	Other potential improvements:
100	+
101	+	On desktop systems, Chrome's GPU process and browser process are separate processes that have different sandboxing rules. On Android however (at time of writing in 2020), all of the stuff that's in the GPU process is actually run from a thread in the browser process. Arguably Chrome on Android's design gives you a wider attack surface for the next step in the exploit chain than would be strictly necessary, and increasing process isolation would mean you could further lock down the seccomp-bpf policies.
102	+
103	+	### 0-day detection methods
104	+
105	+	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? N/A
106	+
107	+	## Other References
108	+
109	+	* February 2021: "Déjà vu-lnerability: A Year in Review of 0-days Exploited In-the-Wild in 2020" [blogpost](https://googleprojectzero.blogspot.com/2021/02/deja-vu-lnerability.html)
110	+	* September 2020: "Attacking the Qualcomm Adreno GPU" [blogpost](https://googleprojectzero.blogspot.com/2020/09/attacking-qualcomm-adreno-gpu.html)
111	+	* August 2020: Guang Gong presented on CVE-2019-5870, a related bug at Blackhat USA 2020, "TiYunZong: An Exploit Chain to Remotely Root Modern Android Devices - Pwn Android Phones from 2015 to 2020" [[video](https://www.youtube.com/watch?v=K91SrkKt4IQ), [slides](https://i.blackhat.com/USA-20/Thursday/us-20-Gong-TiYunZong-An-Exploit-Chain-To-Remotely-Root-Modern-Android-Devices.pdf), [white paper](https://i.blackhat.com/USA-20/Thursday/us-20-Gong-TiYunZong-An-Exploit-Chain-To-Remotely-Root-Modern-Android-Devices-wp.pdf)]
112	+
113	+