Skip links

Fix network printing or keep Windows secure? Admins would rather disable PrintNightmare patch

Microsoft’s Patch Tuesday update last week was meant to fix print vulnerabilities in Windows but also broke network printing for many, with some admins disabling security or removing the patch to get it working.

The problem is complex and first surfaced in January, when Microsoft issued this support note explaining that “a security bypass vulnerability exists in the way the Printer Remote Procedure Call (RPC) binding handles authentication for the remote Winspool interface.”

Microsoft’s fix was in two phases, first to add a registry setting to increase the authorization level for remote access to printers and second, to inform admins that “the release transitions into the enforcement phase on September 14, 2021. Enforcement phase enforces the changes to address CVE-2021-1678 by increasing the authorization level without having to set the registry value.” That September date was “Patch Tuesday” last week – though some admins were already having issues with network printing caused by Microsoft’s other mitigation efforts.

The print nightmare escalated in June when researchers discovered that the print spooler privilege execution vulnerability meant that a compromise of one desktop PC in a network could result in an attacker getting domain administration privileges, since the print spooler runs by default on servers including domain controllers.

This discussion on Microsoft’s question and answer forum for IT professionals shows the problems administrators now face. “This just hit us this morning too. 9/15/2021. No one can print to the network printers. I removed KB5005613 from our server and rebooted the server and that fixed it,” said one such last week – but removing a security patch is not a good solution as it leaves a known vulnerability in place.

Another found a fix that “worked immediately” – a Group Policy Object (GPO) setting which applies across all targeted computers on a Windows network called RestrictDriverInstallationToAdministrators = 0. Unfortunately, this too undoes the security Microsoft is trying to apply. Setting this is not recommended.

Although Microsoft has published a certain amount of information, it could do more in terms of providing guidance to administrators confronted with security issues on the one hand, and users demanding to be able to print on the other. Others have come up with guidance of their own, including this security post which includes a flowchart to analyse print security in a network.

Unofficial flowchart for analysing print security on a Windows network

Unofficial flowchart for analysing print security on a Windows network

It appears that Microsoft has so far been unable to fix the vulnerabilities in Windows network printing by patching the code and has focused instead on tightening the security around it. A typical Windows network has printers of varying age, from various vendors, with various levels of support. Relevant factors include the way in which network printing is configured, the printer drivers used both on client and server, the version of Windows and its patch level, and the GPOs applied to the PCs.

The type of printer driver called V4 is preferred for security but must be installed on the client. In the case of older versions of Windows such as Windows Server 2008 R2, for which extended support has expired, “customers are required to purchase the Extended Security Update,” said Microsoft in the above-mentioned support note. Considering the complexity it is not surprising that some admins have complained of random behaviour.

“I really don’t know if this breaks the PrinterNightmare fix. But our >3,000 customers had to print again…” said one admin in the discussion. That is not a good spot to be in and it seems the PrintNightmare saga is not over yet. We have asked Microsoft for further comment and will report back accordingly. ®