STRLCPY/0days-in-the-wild

CVE-2021-1647 Windows Defender RCA

Change-Id: I43dfa034c1811cda0fee2cc135ac55780004f447

Maddie Stone committed 3 years ago

5685758e

1 parent c651d6dc

Total 1 files

■ ■ ■ ■ ■ ■

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

1	+	# CVE-2021-1672: Windows Defender mpengine remote code execution
2	+	Maddie Stone
3	+
4	+	## The Basics
5	+
6	+	Disclosure or Patch Date: 12 January 2021
7	+
8	+	Product: Microsoft Windows Defender
9	+
10	+	Advisory: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1647
11	+
12	+	Affected Versions: Version 1.1.17600.5 and previous
13	+
14	+	First Patched Version: Version 1.1.17700.4
15	+
16	+	Issue/Bug Report: N/A
17	+
18	+	Patch CL: N/A
19	+
20	+	Bug-Introducing CL: N/A
21	+
22	+	Reporter(s): Anonymous
23	+
24	+	## The Code
25	+
26	+	Proof-of-concept:
27	+
28	+	Exploit sample: [6e1e9fa0334d8f1f5d0e3a160ba65441f0656d1f1c99f8a9f1ae4b1b1bf7d788](https://www.virustotal.com/gui/file/6e1e9fa0334d8f1f5d0e3a160ba65441f0656d1f1c99f8a9f1ae4b1b1bf7d788/detection)
29	+
30	+	Did you have access to the exploit sample when doing the analysis? Yes
31	+
32	+	## The Vulnerability
33	+
34	+	Bug class: Heap buffer overflow
35	+
36	+	Vulnerability details:
37	+
38	+	There is a heap buffer overflow when Windows Defender (`mpengine.dll`) processes the section table when unpacking an [ASProtect](http://www.aspack.com) packed executable. Each section entry has two values: the virtual address and the size of the section. The code in `CAsprotectDLLAndVersion::RetrieveVersionInfoAndCreateObjects` only checks if the next section entry's address is lower than the previous one, not if they are equal. This means that if you have a section table such as the one used in this exploit sample: `[ (0,0), (0,0), (0x2000,0), (0x2000,0x3000) ]`, 0 bytes are allocated for the section at address 0x2000, but when it sees the next entry at 0x2000, it simply skips over it without exiting nor updating the size of the section. 0x3000 bytes will then be copied to that section during the decompression, leading to the heap buffer overflow.
39	+
40	+	```c
41	+	if ( next_sect_addr > sect_addr )// current va is greater than prev (not also eq)
42	+	{
43	+	sect_addr = next_sect_addr;
44	+	sect_sz = (next_sect_sz + 0xFFF) & 0xFFFFF000;
45	+	}
46	+	// if next_sect_addr <= sect_addr we continue on to next entry in the table
47	+
48	+	[...]
49	+	new_sect_alloc = operator new[](sect_sz + sect_addr);// allocate new section
50	+	[...]
51	+
52	+	```
53	+
54	+	Patch analysis: There are quite a few changes to the function `CAsprotectDLLAndVersion::RetrieveVersionInfoAndCreateObjects` between version 1.1.17600.5 (vulnerable) and 1.1.17700.4 (patched). The directly related change was to add an `else` branch to the comparison so that if any entry in the section array has an address less than or equal to the previous entry, the code will error out and exit rather than continuing to decompress.
55	+
56	+	Thoughts on how this vuln might have been found _(fuzzing, code auditing, variant analysis, etc.)_:
57	+
58	+	It seems possible that this vulnerability was found through fuzzing or manual code review. If the ASProtect unpacking code was included from an external library, that would have made the process of finding this vulnerability even more straightforward for both fuzzing & review.
59	+
60	+	(Historical/present/future) context of bug:
61	+
62	+	## The Exploit
63	+
64	+	(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).)
65	+
66	+	Exploit strategy (or strategies):
67	+
68	+	1. The heap buffer overflow is used to overwrite the data in an object stored as the first field in the `lfind_switch` object which is allocated in the `lfind_switch::switch_out` function.
69	+	2. The two fields that were overwritten in the object pointed to by the `lfind_switch` object are used as indices in `lfind_switch::switch_in`. Due to no bounds checking on these indices, another out-of-bounds write can occur.
70	+	3. The out of bounds write in step 2 performs an `or` operation on the field in the `VMM_context_t` struct (the virtual memory manager within Windows Defender) that stores the length of a table that tracks the virtual mapped pages. This field usually equals the number of pages mapped * 2. By performing the 'or' operations, the value in the that field is increased (for example from 0x0000000C to 0x0003030c. When it's increased, it allows for an additional out-of-bounds read & write, used for modifying the memory management struct to allow for arbitrary r/w.
71	+
72	+	Exploit flow:
73	+
74	+	The exploit uses "primitive bootstrapping" to to use the original buffer overflow to cause two additional out-of-bounds writes to ultimately gain arbitrary read/write.
75	+
76	+	Known cases of the same exploit flow: Unknown.
77	+
78	+	Part of an exploit chain? Unknown.
79	+
80	+	## The Next Steps
81	+
82	+	### Variant analysis
83	+
84	+	Areas/approach for variant analysis (and why):
85	+
86	+	* Review ASProtect unpacker for additional parsing bugs.
87	+	* Review and/or fuzz other unpacking code for parsing and memory issues.
88	+
89	+	Found variants: N/A
90	+
91	+	### Structural improvements
92	+
93	+	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.?
94	+
95	+	Ideas to kill the bug class:
96	+
97	+	* Building `mpengine.dll` with ASAN enabled should allow for this bug class to be caught.
98	+	* Open sourcing unpackers could allow more folks to find issues in this code, which could potentially detect issues like this more readily.
99	+
100	+	Ideas to mitigate the exploit flow:
101	+
102	+	* Adding bounds checking to anywhere indices are used. For example, if there had been bounds checking when using indices in `lfind_switch::switch_in`, it would have prevented the 2nd out-of-bounds write which allowed this exploit to modify the `VMM_context_t` structure.
103	+
104	+	Other potential improvements:
105	+
106	+	It appears that by default the Windows Defender emulator runs outside of a sandbox. In 2018, there was this [article](https://www.microsoft.com/security/blog/2018/10/26/windows-defender-antivirus-can-now-run-in-a-sandbox/) that Windows Defender Antivirus can now run in a sandbox. The article states that when sandboxing is enabled, you will see a content process `MsMpEngCp.exe` running in addition to `MsMpEng.exe`. By default, on Windows 10 machines, I only see `MsMpEng.exe` running as `SYSTEM`. Sandboxing the anti-malware emulator by default, would make this vulnerability more difficult to exploit because a sandbox escape would then be required in addition to this vulnerability.
107	+
108	+	### 0-day detection methods
109	+
110	+	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?
111	+
112	+	* Detecting these types of 0-days will be difficult due to the sample simply dropping a new file with the characteristics to trigger the vulnerability, such as a section table that includes the same virtual address twice. The exploit method also did not require anything that especially stands out.
113	+
114	+	## Other References
115	+
116	+	* February 2021: [浅析 CVE-2021-1647 的漏洞利用技巧("Analysis of CVE-2021-1647 vulnerability exploitation techniques")](https://www.anquanke.com/post/id/231625) by Threatbook