One cannot help but empathize with the beleaguered software engineers burning the midnight oil to sift through decades of legacy code that is at the heart of the PrintNightmare exploit. To its credit, and amid a mass of confusion, Microsoft recognized the urgency and expedited patch development. The emergency patch release occurred on July 6, 2021, less than a week before Microsoft’s regular “Patch Tuesday” on July 13, 2021. The cynical among us, who have endured the experience of eerily similar patch cycles, are right to approach this emergency patch release with a healthy amount of skepticism.
It appears that Microsoft is out of step with the refinements made to PrintNightmare by the security community in the span of just the last week. Within two days of the original exploit code being made available on GitHub, several forked copies of the code base had been advanced making the exploit more robust, discovering additional code paths, and identifying trigger conditions more complex than the original. Early testing of the refined exploits confirms suspicions that the emergency patches had been too hastily assembled to completely remediate the vulnerabilities. At this time, it is known that some test cases are no longer viable. More testing and tweaks to the refined exploits may win out, but it is too early to say at this point.
While we cannot know the internal risk calculations made by Microsoft, there is some data that we can draw upon to make our own risk calculations. One fact that cannot be ignored is that if the Print Spooler service were disabled, Windows servers and endpoints are not vulnerable to PrintNightmare. They are automatically immune to the PrintNightmare exploit, its variants, and the effects of incremental patching of the service implementation code. Huy (@DebugPrivilege), a Microsoft and Windows Insider MVP, conducted a Twitter poll among administrators on July 2, 2021. Among 193 respondents, 58% indicated they had disabled the Print Spooler service in their infrastructure server baselines. Another 24.9% indicated they had not and 17.1% were unsure. Taking these percentages at face value, confronted with untested emergency patches known to be incomplete, and knowing the next Windows patch cycle is about to begin, how then do we manage the situation? That is the question many managers will need to answer today.
If your organization, or parts thereof, have a robust and efficient patching program, it can make sense to expedite patch testing and deployment in those areas and hope for a significant reduction in the attack surface area. Provided the emergency patches do not break something else, installing them is a good option. On the other hand, if your organization, or parts thereof, have a complex patching process, it can be difficult to justify the disruption to operations—especially when the next monthly patch cycle is upon us. Managing the expedite of an out-of-band patch cycle in those areas requires the same amount of time, budget, and labor as a normal patch window, but with a corresponding loss in operational capability. In this case, it might be more practical to use the extra week to continue with the mitigations recommended by Microsoft for all servers and workstations not servicing a printer. Mitigation activities in lieu of any out-of-band patching would simultaneously reduce your attack surface area and strengthen your security baselines. It would also allow for avoiding the grief costs associated with the inevitable incremental patching for PrintNightmare and its variants.
The nightmare is not over. There are indications that we can expect a raft of related vulnerabilities. Plan accordingly.
UPDATE July 7, 2021: Alas, the inevitable prediction of just eight hours ago, has come true. Benjamin Delpy (@gentilkiwi), creator of the well-known open source mimikatz application and owner of one of the first copies of the PrintNightmare GitHub repositories, has shown the Microsoft emergency patch for CVE-2021-34527 to be ineffective in at least one common configuration. His finding was shortly thereafter corroborated by Will Dormann (@wdormann), a vulnerability analyst at the Computer Emergency Response Team/Coordination Center (CERT/CC) of Carnegie Mellon University. The configuration under test is known as “Point and Print” in Windows which allows a computer user to connect with a network printer without needing to have the installation media to load its driver software. To make that experience as smooth as possible for computer users, Microsoft Windows includes a configuration setting, that when enabled, suppresses both warnings and prompts for privilege elevation. In effect, when enabled, which is commonplace, it silently forces (potentially malicious) driver software from a network printer to load thereby allowing it to interact with the computer at the level of operating system software. In this configuration, fully patched Windows computers—including the emergency patch release—are vulnerable to both the local privilege escalation (LPE) and remote code execution (RCE) components of the revised PrintNightmare exploits.