by Mitja Kolsek, the 0patch Team
[Note: This blog post is expected to be updated as new micropatches are issued and new information becomes available.]
Update 7/16/2021: We've ported and issued our PrintNightmare patches for Windows computers that have July 2021 Windows Updates installed (which we do recommend). Our patches prevent exploitation of PrintNightmare even if computer settings render Microsoft's patch ineffective, as described by Will Dormann's diagram. These patches remain free for now.
Update 7/15/2021: July Patch Tuesday patches included the same PrintNightmare fix as the July 6 out-of-band Windows Update, with Microsoft stating that it properly resolves the vulnerability. As this diagram shows, two configuration options that aren't inherently security-related can make the system vulnerable to at least local - but likely also remote - attack, so we're going to port our patches to at least July Windows Updates while we continue to assess the situation. Since July Windows Updates also brought fixes for various other vulnerabilities, we recommend applying them to keep your computers fully up-to-date.
Update 7/7/2021: Microsoft has issued an out-of-band update for the PrintNightmare vulnerability, but the next day this update was found to be ineffective for both local and remote attack vectors. The update does, however, modify localspl.dll on the computer, which means that our existing patches stop getting applied to this module if the update is installed. In other words, if you used 0patch to protect your computers against PrintNightmare, applying the July 6 update from Microsoft makes you vulnerable again. Since we expect Microsoft to issue another modification to localspl.dll next week on Patch Tuesday, we decided not to port our patches to the July 6 version of localspl.dll but rather wait and see what happens next week. Consequently, we recommend NOT INSTALLING the July 6 Windows update if you're using 0patch.
Update 7/5/2021: Security researcher cube0x0 discovered another attack vector for this vulnerability, which significantly expands the set of affected machines. While the original attack vector was Print System Remote Protocol [MS-RPRN], the same attack delivered via Print System Asynchronous Remote Protocol [MS-PAR] does not require Windows server to be a domain controller, or Windows 10 machine to have UAC User Account Control disabled or PointAndPrint NoWarningNoElevationOnInstall enabled. Note that our patches for Servers 2019, 2016, 2012 R2 and 2008 R2 issued on 7/2/2021 are effective against this new attack vector and don't need to be updated.
June 2021 Windows Updates brought a fix for a vulnerability CVE-2021-1675 originally titled "Windows Print Spooler Local Code Execution Vulnerability". As usual, Microsoft's advisory provided very little information about the vulnerability, and very few probably noticed that about two weeks later, the advisory was updated to change "Local Code Execution" to "Remote Code Execution".
This CVE ID would probably remain one of the boring ones without a surprise publication of a proof-of-concept for a remote code execution vulnerability called PrintNightmare, indicating that it was CVE-2021-1675. Security researchers Zhiniang Peng and Xuefeng Li, who published this POC, believed that their vulnerability was already fixed by Microsoft, and saw other researchers slowly leaking details, so they decided to publish their work as well.
It turned out that PrintNightmare was not, in fact, CVE-2021-1675 - and the published details and POC were for a yet unpatched vulnerability that turned out to allow remote code execution on all Windows Servers from version 2019 back to at least version 2008, especially if they were configured as domain controllers.
The security community went scrambling to clear the confusion, identify conditions for exploitability, and find workarounds in absence of an official fix from Microsoft. Meanwhile, PrintNightmare started getting actively exploited, Microsoft has confirmed it to be a separate vulnerability to CVE-2021-1675, assigned it CVE-2021-34527, and recommended that affected users either disable the Print Spooler service or disable inbound remote printing.
In addition to Microsoft's recommendations, workarounds gathered from the community included removing Authenticated Users from the "Pre-Windows 2000 Compatible Access" group, and setting permissions on print spooler folders to prevent the attack.
Patching the Nightmare
Long story short, our team at 0patch has analyzed the vulnerability and created micropatches for different affected Windows versions, starting with those most critical and most widely used:
- Windows Server 2019 (updated with June 2021 Updates)
- Windows Server 2016 (updated with June 2021 Updates)
- Windows Server 2012 R2 (updated with June 2021 Updates)
- Windows Server 2008 R2 (updated with January 2020 Updates, no Extended Security Updates)
- Windows 10 v21H1 (updated with June 2021 Updates)
- Windows 10 v20H2 (updated with June 2021 Updates)
- Windows 10 v2004 (updated with June 2021 Updates)
- Windows 10 v1909 (updated with June 2021 Updates)
- Windows 10 v1903 (updated with December 2020 Updates - latest before end of support)
- Windows 10 v1809 (updated with May 2021 Updates - latest before end of support)
- Windows 10 v1803 (updated with May 2021 Updates - latest before end of support)
- Windows 10 v1709 (updated with October 2020 Updates - latest before end of support)
- Windows 7 (updated with January 2020 Updates, no Extended Security Updates)
[Note: Additional patches will be released as needed based on exploitability on different Windows platforms.]
Our micropatches prevent the APD_INSTALL_WARNED_DRIVER flag in dwFileCopyFlags of function AddPrinterDriverEx from bypassing the object access check, which allowed the attack to succeed. We believe that "install warned drivers" functionality is not a very often used one, and breaking it in exchange for securing Windows machines from trivial remote exploitation is a good trade-off.
Our PrintNightmare patch only contains one single instruction, setting the rbx register to 1 and thus forcing the execution towards the code block that performs said object access check.
Or as we see it in IDA Pro (green code block is injected by 0patch, grey is the original code that had to be moved in order to inject a jmp instruction in its place to jump to the patch).
See our micropatch in action:
Micropatches for PrintNightmare will be free until Microsoft has issued an official fix. If you want to use them, create a free account at 0patch Central, then install and register 0patch Agent from 0patch.com. Everything else will happen automatically. No computer reboots will be needed.
Compatibility note: Some Windows 10 and Server systems exhibit occasional timeouts in the Software Protection Platform Service (sppsvc.exe) on a system running 0patch Agent. This looks like a bug in Windows Code Integrity
mitigation that prevents a 0patch component to be injected in the
service (which is okay) but sometimes also does a lot of seemingly
meaningless processing that causes process startup to time out. As a
result, various licensing-related errors can occur. The issue, should it
occur, can be resolved by excluding sppsvc.exe from 0patch injection as described in this article.
Frequently Asked Questions
Q: Which Windows versions are affected by PrintNightmare?
Answer updated 7/15/2021: We believe Will Dormann's PrintNightmare diagram most accurately describes the conditions under which PrintNightmare is exploitable, and this applies to all Windows versions at least back to Windows 7 and Server 2008 R2.
We have previously thought that domain-joined computers were not vulnerable but this was likely because by joining a domain, firewall rules were set up that blocked remote exploitation until one started sharing a folder or a printer.
Q: How about Windows systems without June 2021 Windows Updates?
We believe that without June 2021 Windows Updates, all supported Windows systems, i.e., all servers from 2008 R2 up and all workstations from Windows 7 and up, are affected.
Q: What will happen with these micropatches when Microsoft issues their own fix for PrintNightmare?
[Update 7/15/2021: We recommend everyone continues applying regular Windows Updates, including specifically the July Patch Tuesday update.]
First off, we
absolutely usually recommend you do install all available security updates from original vendors [Update 7/8/2021: For the first time ever we do NOT recommend installing the July 6 update if you're using 0patch. See the top of the article for more information].When Microsoft fixes PrintNightmare, their update will almost certainly replace localspl.dll, where the vulnerability resides, and where our micropatches are getting applied. Applying the update will therefore modify the cryptographic hash of this file, and 0patch will stop applying our micropatches to it. You won't have to do anything in 0patch (such as disabling a micropatch), this will all happen automatically by 0patch design.
When the official fix is available, our micropatches will stop being free, and will fall under the 0patch PRO license. This means that if you wish to continue using them (and many other micropatches that the PRO license includes), you will have to purchase the appropriate amount of licenses.
[Update 7/8/2021: We do not consider Microsoft's July 6 out-of-band updates to be a proper fix, so we're keeping our PrintNightmare patches free until they issue a correct fix.]
Q: I have installed 0patch but the PrintNightmare patch is not applied. Why?
The Print Spooler service doesn't initially load localspl.dll when you start it, so it's probably not loaded yet. When it's needed (e.g., when installing a new printer, probably also when you print, and certainly if you launch a PrintNightmare proof-of-concept or exploit against it), localspl.dll gets loaded, and patched by 0patch.
To be sure you have the correct version of localspl.dll, launch 0patch Console and open the PATCHES -> RELEVANT PATCHES tab. At least one PrintNightmare patch should be listed there.
Q: We have a lot of affected computers. How can we prepare for the next Windows 0day?
Obviously deploying 0patch in an enterprise production environment on a Friday afternoon is not something most organizations would find optimal. As with any enterprise software, we recommend testing 0patch with your existing software on a group of testing computers before deploying across your network. Please contact email@example.com for setting up a trial, and when the next 0day like this comes out, you'll be ready to just flip a switch in 0patch Central and go home for the weekend.
We'd like to thank Will Dormann of CERT/CC for behind-the-scenes technical discussion that helped us understand the issue and decide on the best way to patch it.
Please revisit this blog post for updates or follow 0patch on Twitter.