Back in June, Microsoft released a fix for a vulnerability in the Windows operating system that enabled attackers to increase their permissions to kernel level on a compromised machine. The patch did not stick.
The issue, which advanced hackers exploited as a zero-day in May, is still exploitable but by a different method as security researchers demonstrate with publicly available proof-of-concept code.
Old new vulnerability
Google Project Zero security researcher Maddie Stone discovered that Microsoft’s patch in June did not fix the original vulnerability (CVE-2020-0986) and it can still be leveraged with some adjustments.
In May 2020, the issue was exploited in the wild for privilege escalation along with a bug in Internet Explorer that allowed remote code execution. Both flaws were zero-days at the time of the attack discovered by Kaspersky.
Stone says that an attacker can still trigger CVE-2020-0986 to increase their permissions to kernel level by sending an offset instead of a pointer.
On Twitter, the researcher spells it out saying that the original bug was an arbitrary pointer dereference allowing an attacker to control the “src” and “dest” pointers to a memcpy function.
Microsoft’s patch was improper because it changed the pointers to offsets, so the function’s parameters could still be controlled.
In a short, technical report today, she explains how to trigger the vulnerability, now identified as CVE-2020-17008:
A low integrity process can send LPC messages to splwow64.exe (Medium integrity) and gain a write-what-where primitive in splwow64’s memory space. The attacker controls the destination, the contents that are copied, and the number of bytes copied through a memcpy call. The offset for the destination pointer calculation is only constrained to be:
Offset <= 0x7FFFFFFF
Offset + perceived size of structure <= 0x7FFFFFFF
Splwow64 passes the LPC message to GdiPrinterThunk. The vulnerable memcpy is in message 0x6D.To show that exploitation is still possible after Microsoft’s patch, Stone published proof-of-concept (PoC) code adapted from the original one from Kaspersky, along with instructions on how to run it properly.
The researcher adds that what the PoC does is trigger the vulnerability twice: “first to leak the heap address where the message is stored and what the offset is added to generate the pointers and then to do the write-what-where.”
Microsoft received a report on September 24 and confirmed the issue a day later, assigning it the tracking number CVE-2020-17008. The company planned a patch for November 2020, but problems identified during the testing stage pushed the release to the next Patch Tuesday, on January 12, 2021.
Google Project Zero has a vulnerability disclosure policy of 90 days, with an extension of 14 days if more time is needed to push a fix. As Microsoft informed that a patch would not be available before January 6, neither of the two deadlines could be met.
Furthermore, as Stone says, attackers have exploited the bug in the past, are familiar with it, and could leverage it again when an incorrect fix is available.