STRLCPY/0days-in-the-wild

Added CVE-2021-33742 RCA

Change-Id: I11f0605e52c392621f04eaf7567f4976c33db58e

Maddie Stone committed 3 years ago

fd85e0d2

1 parent 54a2bf2f

Total 1 files

■ ■ ■ ■ ■ ■

0day-RCAs/2021/CVE-2021-33742.md

1	+	# CVE-2021-33742: Internet Explorer out-of-bounds write in MSHTML
2	+	Maddie Stone, Google Project Zero & Threat Analysis Group
3	+
4	+	## The Basics
5	+
6	+	Disclosure or Patch Date: 03 June 2021
7	+
8	+	Product: Microsoft Internet Explorer
9	+
10	+	Advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-33742
11	+
12	+	Affected Versions: For Windows 10 20H2 x64, [KB5003173](https://support.microsoft.com/en-us/topic/may-11-2021-kb5003173-os-builds-19041-985-19042-985-and-19043-985-2824ace2-eabe-4c3c-8a49-06e249f52527) and previous
13	+
14	+	First Patched Version: For Windows 10 20H2 x64, [KB5003637](https://support.microsoft.com/en-us/topic/june-8-2021-kb5003637-os-builds-19041-1052-19042-1052-and-19043-1052-fd782405-7736-478e-b8d0-b08f735f7e54)
15	+
16	+	Issue/Bug Report: N/A
17	+
18	+	Patch CL: N/A
19	+
20	+	Bug-Introducing CL: N/A
21	+
22	+	Reporter(s): Clément Lecigne of Google’s Threat Analysis Group
23	+
24	+	## The Code
25	+
26	+	Proof-of-concept:
27	+
28	+	Proof-of-concept by Ivan Fratric of Project Zero
29	+	```html
30	+	<script>
31	+	alert(1);
32	+	var b = document.createElement("html");
33	+	b.innerHTML = Array(40370176).toString();
34	+	b.innerHTML = "";
35	+	alert(2);
36	+	</script>
37	+
38	+	```
39	+
40	+	Exploit sample:
41	+
42	+	Examples of the Word documents used to distribute this exploit:
43	+
44	+	* [656d19186795280a068fcb97e7ef821b55ad3d620771d42ed98d22ee3c635e67](https://www.virustotal.com/gui/file/656d19186795280a068fcb97e7ef821b55ad3d620771d42ed98d22ee3c635e67/detection)
45	+	* [851bf4ab807fc9b29c9f6468c8c89a82b8f94e40474c6669f105bce91f278fdb](https://www.virustotal.com/gui/file/851bf4ab807fc9b29c9f6468c8c89a82b8f94e40474c6669f105bce91f278fdb/detection)
46	+
47	+	Did you have access to the exploit sample when doing the analysis? Yes
48	+
49	+	## The Vulnerability
50	+
51	+	Bug class: Out-of-bounds write
52	+
53	+	Vulnerability details:
54	+
55	+	The vulnerability is due to the size of the string of the inner html element being truncated (size&0x1FFFFFF) in the `CTreePos` structure while the non-truncated size is still in the text data object. Memory at [1] is allocated based on the size in the `CTreePos` structure, the truncated size.
56	+
57	+	The text data returned by `MSHTML!Tree::TextData::GetText` [2] includes the full non-truncated length of the string. The non-truncated length is then passed as the src length to `wmemcpy_s` [3] while the allocated destination memory uses the truncated length. While `wmemcpy_s` protects against the buffer overflow here, the source size is used as the increment even though that was not the number of bytes actually copied: the size of the allocation was. The index (`v190`) is incremented by the larger number. When that index is then used to access the memory allocated at [1], it leads to the out of bounds write at
58	+	`MSHTML!CSpliceTreeEngine::RemoveSplice+0xb1f`.
59	+
60	+
61	+	```c
62	+	if ( v172 >= 90000 && ((_BYTE)v4[21] & 4) != 0 )
63	+	{
64	+	v70 = 1 - CTreePos::GetCp(v4[5]);
65	+	v71 = CTreePos::GetCp(v4[6]); /* v71 = Truncated size (orig_sz&0x1ffffff) */
66	+	v72 = v4[6];
67	+	v104 = ((_BYTE )v72 & 4) == 0;
68	+	v189 = (CTreeNode *)(v70 + v71);
69	+	if ( !v104 )
70	+	{
71	+	v73 = CTreeDataPos::GetTextLength(v72);
72	+	v189 = (CTreeNode *)(v73 + v74 - 1);
73	+	}
74	+	if ( v184 <= (int)v187 )
75	+	{
76	+	v77 = (struct CMarkup )operator new[]( / [1] allocates based on truncated size */
77	+	(unsigned int)newAlloc,
78	+	(const struct MemoryProtection::leaf_t *)newAllocSz);
79	+	v4[23] = v77;
80	+	if ( v77 )
81	+	{
82	+	for ( i = v4[5]; i != ((struct CMarkup )v4[6] + 5); i = (struct CMarkup )((_DWORD )i + 5) )
83	+	{
84	+	if ( ((_BYTE )i & 4) != 0 )
85	+	{
86	+
87	+	/* [2] srcTextSz is non truncated size */
88	+	srcText = Tree::TextData::GetText(((Tree::TextData *)i + 8), 0, &srcTextSz);
89	+
90	+	/* [3] -- srcTextSz > newAllocSz */
91	+	wmemcpy_s(srcText, srcTextSz, (const wchar_t *)newAlloc, (rsize_t)newAllocSz);
92	+
93	+	/* memcpy only copied newAllocSz not srcTextSz so v190 is now > max */
94	+	v190 += srcTextSz;
95	+	}
96	+	else if ( ((_BYTE )i & 3) != 0 && ((_BYTE )i & 0x40) != 0 )
97	+	{
98	+	v80 = v190;
99	+	((_WORD )v4[23] + (_DWORD)v190) = 0xFDEF;
100	+	v190 = v80 + 1;
101	+	}
102	+	}
103	+	}
104	+
105	+
106	+	```
107	+
108	+	Patch analysis:
109	+
110	+	The patch is in `Tree::TreeWriter::NewTextPosInternal`. The patch will cause a release assert if there is an attempt to add `TextData` greater than 0x1FFFFFFF to the HTML tree.
111	+
112	+	Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:
113	+
114	+	This vulnerability was likely found via fuzzing. A fuzzer may not have found this vulnerability if your fuzzer runs with a tight timeout since this vulnerability takes a few seconds to trigger. It still seems more likely that this would have been found via fuzzing rather than manual review.
115	+
116	+	(Historical/present/future) context of bug:
117	+
118	+	See this [Google TAG blogpost](https://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks) for more info. Malicious Office documents loaded web content within Internet Explorer. The malicious document would fingerprint the device and then send this Internet Explorer website to users.
119	+
120	+	## The Exploit
121	+
122	+	(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).)
123	+
124	+	Exploit strategy (or strategies): Still under analysis.
125	+
126	+	Exploit flow:
127	+
128	+	Known cases of the same exploit flow:
129	+
130	+	Part of an exploit chain?
131	+
132	+	This vulnerability was likely paired with a sandbox escape, but that was not collected.
133	+
134	+	## The Next Steps
135	+
136	+	### Variant analysis
137	+
138	+	Areas/approach for variant analysis (and why):
139	+
140	+	It seems possible that there would be more of these types of instances throughout the code base if `CTreePos` structures are truncating the sizes to 25 bits while other areas, such as `TextData` are not. The top 7 bits of the size in the `CTreePos` struct are used as flags.
141	+
142	+	Found variants: N/A
143	+
144	+	### Structural improvements
145	+
146	+	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.?
147	+
148	+	Ideas to kill the bug class:
149	+
150	+	* If truncating the size/length of an object, do the bounds checking/input validation of the size at the earliest point and only store the truncated size.
151	+	* Kill the tab process when the size reaches the size that can no longer be properly represented.
152	+
153	+	Ideas to mitigate the exploit flow: N/A
154	+
155	+	Other potential improvements:
156	+
157	+	[Microsoft has announced](https://blogs.windows.com/windowsexperience/2021/05/19/the-future-of-internet-explorer-on-windows-10-is-in-microsoft-edge/) that Internet Explorer will be retired in June 2020. However, it also says that the retirement does not affect the MSHTML (Trident) engine. This means that `mshtml.dll` where this vulnerability exists is not planning to be retired. In the future, if a user enables IE mode in Edge, the mshtml engine would be used. It seems likely that Office will still have access to mshtml. Limiting access to mshtml and audit applications that use mshtml.
158	+
159	+	### 0-day detection methods
160	+
161	+	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?
162	+
163	+	Variants of this bug could potentially be detected by looking for javascript that tries to create objects with sizes greater than the allowed bounds.
164	+
165	+	## Other References
166	+	* July 2021: ["How We Protect Users From 0-Day Attacks"](https://blog.google/threat-analysis-group/how-we-protect-users-0-day-attacks
167	+	) by Google's Threat Analysis Group gives context about how this exploit was used.