This page has been moved to our new site. Please click here to go to the new location.
Posted by Maddie Stone, Project Zero
Disclosure or Patch Date: 19 May 2020 (ZDI Disclosure) & 9 June 2020 (Microsoft)
Product: Microsoft Windows
Advisory:
First Patched Version:
Issue/Bug Report: N/A
Patch CL: N/A
Bug-Introducing CL: N/A
Proof-of-Concept: See below.
Exploit Sample: N/A
Exploit Sample: N/A
Access to the exploit sample? No
Reporter(s): Boris Larin (Oct0xor) of Kaspersky Lab
Bug Class: Untrusted Pointer Dereference
Vulnerability Details: The vulnerability is almost exactly the same as CVE-2019-0880 [detailed technical analysis]. Just like CVE-2019-0880, this vulnerability allows the attacker to call memcpy with arbitrary parameters in the splwow64 privileged address space. The arbitrary parameters are sent in an LPC message to splwow64.
In this case, the vulnerable message type is 0x6D, which is the call to DocumentEvent. After DocumentEvent is called from GdiPrinterThunk, a call to memcpy can occur as long as you craft specific fields in your LPC message to the right values. This memcpy call is at gdi32full!GdiPrinterThunk+0x1E85A.
The message that is sent via LPC is 0x20 bytes long. This 0x20 data block follows a header that is 0x28 bytes long. The data block includes the following values:
The buffers for msg_send and msg_reply need to be created in memory that’s shared by the calling process & splwow64. In the POC below, this is created using _PORT_VIEW struct.
The pointers to msg_send and msg_reply are passed as the two arguments to GDIPrinterThunk. In order to trigger the vulnerable memcpy, the contents of msg_send must be:
The size of the memcpy is at [src of memcpy + 0x40].
With RCE in the less privileged Internet Explorer renderer, one can send this LPC message and receive arbitrary write primitive in splwow64’s more privileged address space.
Is the exploit method known? N/A
Exploit method: I have not seen a copy of the exploit so I don’t know what exploit method was used.
Exploit method: I have not seen a copy of the exploit so I don’t know what exploit method was used.
How do you think you would have found this bug? This bug is very shallow and an extremely trivial variant of the previous vulnerability that was exploited in the wild, CVE-2019-0880. Therefore, it’d be pretty easy to find this vulnerability by auditing the GdiPrinterThunk function.
(Historical/present/future) context of bug:
This vulnerability was chained with CVE-2020-1380. CVE-2020-1380 is the Remote Code Execution (RCE) vulnerability and CVE-2020-0986 is the Elevation of Privilege (EoP).
ZDI publicly published a limited advisory on 19 May 2020 about the existence of this vulnerability after their 120-day deadline expired with no patch. Kaspersky reported that they saw this vulnerability exploited in-the-wild on 20 May 2020. For Project Zero’s 0day in-the-wild tracking spreadsheet, we do not include any 0-days that were fully disclosed prior to exploitation. In this case we are still including this vulnerability because the details in ZDI’s bulletin were limited and Microsoft also did not consider the vulnerability publicly disclosed or exploited.
Microsoft’s advisory did not list this vulnerability as Exploited. After asking Microsoft, they said that the 2 reporters who had reported this vulnerability to them had not told them anything about in-the-wild exploitation and they have a policy of not updating the “exploited” flag in advisories if they learn about exploitation after the advisory has been published.
Areas/approach for variant analysis:
- Statically audit GDIPrinterThunk for other untrusted pointer dereferences
- Fuzz LPC messages to legacy components of Windows, like splwow64
Found variants: N/A
Structural improvements:
- Verifying any pointers that are passed in a LPC message in ProcessRequest prior to passing to GdiPrinterThunk.
- The patch for this vulnerability includes Microsoft switching the entries in the LPC messages from pointers to offsets. This will add restrictions to the arbitrary write primitive.
- If Internet Explorer is not able to be deprecated, at least show a pop-up message whenever IE is accessing a process that is whitelisted in Internet Explorer Elevation Policy.
Potential detection methods for similar 0-days:
- If the IE renderer is trying to connect & send messages to splwow64
- Creating shared memory/buffer with splwow64
Other references:
Proof-of-Concept by Boris Larin (oct0xor) of Kaspersky Lab (shared with permission), minimized and commented by Maddie Stone:
No comments:
Post a Comment