UPDATE: July 6, 2021: Security updates (KB5004945) released today contain fixes for CVE-2021-1675 as well as for the remote code execution exploit in the Windows Print Spooler service known as “PrintNightmare”, documented in CVE-2021-34527.
The anticipation of giving a talk at the upcoming Black Hat USA event to be held July 31 - August 3, 2021, entitled “Diving into Spooler: Discovering LPE and RCE Vulnerabilities in Windows Printer” is the backdrop to an apparent misunderstanding between Microsoft and the researchers involved. Zhiniang Peng (@edwardzpeng), a Principal Architect and Researcher at Sangfor, and Xuefeng Li (@lxf02942370), an intern at Sangfor and student at the South China University of Technology (SCUT), are credited with the find. They identified a logic flaw in Windows programming that allows a domain account to bypass the privilege requirement intended for remotely loading printer drivers. In effect, they found a path through the implementation code that allows an unprivileged domain user account to remotely connect to the Print Spooler service on a Domain Controller (DC) and install an arbitrary driver capable of gaining full control over the Domain.
Zhiniang Peng made it known their proposal for giving a talk at Black Hat USA was accepted on May 21, 2021, later to be officially announced by Black Hat USA on June 16, 2021. The team of Xuefeng Li, Zhiniang Peng, and Lewis Lee (@LewisLee53) were set to present their findings of the vulnerability now identified as CVE-2021-1675, or PrintNightmare, as it was dubbed by Sangfor. Meanwhile, the Microsoft Security Response Center (MSRC) published a notice entitled "Windows Print Spooler Elevation of Privilege Vulnerability” for CVE-2021-1675 on June 8, 2021. Notice there is no mention of a remote code execution vulnerability. The timing of its release was undoubtedly intended to coincide with “Patch Tuesday” and Microsoft’s release of their monthly security updates purported to contain a related code fix.
Everyone agrees the researchers had posted their technical write up and Proof-of-Concept (PoC) exploit code for CVE-2021-1675 to a GitHub repository. The Hacker News reported that the repository was subsequently deleted only a few hours later. In that brief period, their repository had already been “forked,” which is software version control parlance for creating a separate branch, or individual copy repository. A standard practice among software developers for working independently of the original code base. The vulnerability researcher’s repository had been forked by at least one person a week ago as of this writing. That means the fork happened, and therefore publication by the researchers happened, on or about June 28, 2021. Indeed, early on June 29, 2021, Zhiniang Peng tweeted that their GitHub repository for CVE-2021-1675 had been deleted but, of course, the forked copies had already been created.
These dates align closely with follow-on work by developers in the community to validate the exploit PoC first observed in the afternoon of June 29, 2021. The timeframe is also significant since it is at the end of the month—three weeks later than the presumed patch publication by Microsoft. Near month’s end is when most servers could be expected to have received the June 8, 2021, security updates. While publishing of technical data and the PoC exploit code have been characterized by some as an irresponsible leak, more plausible is a lack of mutual understanding and coordination between the Microsoft Security Research Center and the vulnerability researchers. Hours after the exploit was published and then forked, the initial results obtained by the security community immediately called into question the patch status of servers under test and then consequently the validity of the patch itself. It must have been obvious, from the vulnerability researcher’s perspective, the Microsoft patch for CVE-2021-1675 was not working as expected and may well be the reason the exploit repository was deleted from GitHub so quickly.
Unclear is whether Microsoft is intentionally downplaying a dangerous zero-day vulnerability, or we are witnessing the cumulative effects of some dysfunction. Regardless of the cause, the cat is out of the bag and there is plenty of confusion surrounding CVE-2021-1675. The researchers themselves, evidenced by the title of their Black Hat talk, understand CVE-2021-1675 to be both a local privilege escalation (LPE) as well as a remote code execution (RCE) vulnerability and have confirmed in a recent tweet that CVE-2021-1675 is indeed the vulnerability known as PrintNightmare. Yet Microsoft appears to be splitting hairs and claims in the FAQ section of their notice for CVE-2021-1675 that it is not. On June 21, 2021, Microsoft changed the title of CVE-2021-1675 to be “Windows Print Spooler Remote Code Execution Vulnerability” and elevated its impact severity to be Critical. A week later, June 27, 2021, QiAnXin Technology (@RedDrip7), a leading Chinese security vendor claimed publicly that Microsoft had misinterpreted CVE-2021-1675 as being a local privilege escalation vulnerability only.
What now seems likely to have occurred is that the vulnerability researchers were on track to publicly disclose CVE-2021-1675 technical detail at Black Hat USA beginning at the end of July, which to their understanding, included both LPE and RCE components. However, Microsoft had only prepared a code fix for the less severely impacting LPE component in their June release of security updates. A fix for the critical RCE component of the exploit may have not been in the works prior to the mix up. With insufficient time to develop, test, and deploy a fix for the RCE, a situation had been created in which code for a dangerous exploit was now available without a corresponding and coordinated patch release.
The Microsoft Security Research Center then issued CVE-2021-34527 on July 1, 2021. It represents the true RCE component of the vulnerability which Microsoft now claims addresses the exploit known as PrintNightmare. At this point, their notice for CVE-2021-1675 is incoherent and is best ignored for the time being. Realize that the patch listed for CVE-2021-1675 addresses the local privilege escalation part of the vulnerability discovered by Zhiniang Peng and his team at Sangfor. Microsoft asserts that while CVE-2021-1675 and CVE-2021-34527 are similar, they are distinctly different CVEs. The conflation of CVE-2021-1675 notwithstanding, the patch is needed. That is why both Microsoft and the vulnerability researchers place emphasis on installing the patch for CVE-2021-1675 even though it does not contain a code fix for the remote code execution—the main thrust—of their vulnerability finding.
What is clear is that something failed in the collaboration process between Microsoft and the Zhiniang Peng vulnerability research team that resulted in the current debacle and thus the scramble to disable the Print Spooler service on all Windows platforms where it is not required.