Over the past year, the MORSE team has been working in collaboration with the Windows Print team to modernize the Windows Print System. This new design represents one of the largest changes to the Windows Print stack in more than 20 years. The goal was to build a more modern and secure print system that maximizes compatibility and puts users first. We are calling this new platform Windows Protected Print Mode (WPP). We believe users should be Secure-by-Default which is why WPP will eventually be on by default in Windows.
Recently, we announced our plan to end servicing for third-party drivers in Windows. Moving away from drivers has allowed us to significantly improve the print stack. This article will explain the case for adopting driverless printing, provide some insights on compatibility, and preview the security improvements provided by Windows Protected Print Mode.
One of the largest motivations behind the change is security. The Windows print system has been a key target for attackers. The Spooler runs with high privileges and must load code from the network which is difficult to accomplish with low friction and high security. Print bugs played a role in Stuxnet and Print Nightmare, and account for 9% of all Windows cases reported to MSRC. Securing the print stack is challenging, in large part due to the use of third-party drivers. WPP blocks all third-party drivers and implements a wide range of new security protections.
To put these changes in some context, MORSE did an analysis of past MSRC cases for Windows Print to assess if these changes would help. What we found is that Windows Protected Print Mode mitigated over half of those vulnerabilities.
Although we know some may find changing configurations inconvenient, we believe it is best for overall user security.
The Driver Problem
The security model for print drivers relies on a shared responsibility approach where the Windows printing stack and third-party drivers must each play a role in providing functionality and enforcing security promises while avoiding introducing vulnerabilities. This is like some other subsystems in Windows, but printing is a particularly challenging scenario because both we and customers want the process to be as frictionless as possible. Balancing security, convenience and backwards compatibility with older devices is challenging. Here are some examples.
Print Nightmare
This vulnerability was the result of an authorization bypass bug which allowed authenticated remote users to install print drivers using the RPC call RpcAddPrinterDriver and specify a driver file located in a remote location. The attacker’s chosen file was then loaded as a DLL and executed in the highly privileged Spooler process, effectively granting the attacker SYSTEM privileges.
Fixing this vulnerability was complicated by the fact that such a feature exists by design called Point and Print which allows for frictionless driver installation by a print server to the client. Remote servers can install drivers without an admin prompt on the client assuming the appropriate configuration (registry setting) on the client. Once a fix was in place, users of V3 drivers, often in larger environments, suddenly found themselves with Admin login prompts when trying to use their printers. Users of V4 drivers did not experience this problem. Although the V4 model was introduced in 2012, 9 years before this vulnerability in 2021, most printers still used V3 drivers. This really speaks to some of the challenges with the driver-based model.
Compatibility
One challenge with print drivers is their age. Some print drivers are decades old and are incompatible with modern security mitigations, such as Control Flow Guard (CFG), Control Flow Enforcement Technology (CET), Arbitrary Code Guard (ACG), and the many other protections Microsoft has implemented over the years. These protections are often “all or nothing,” meaning that all participating binaries must take steps to be compatible for the protection to be effective. Since not every print manufacturer has taken the necessary steps to update these drivers, the print service does not currently benefit from these modern exploit mitigations.
Excessive Permissions
Loading code from third parties presents several challenges from a security perspective. Not only must you ensure you’re loading the code you intended to load, that code may change the behavior of your application in unexpected ways. For example, drivers support complex parsing logic, which can lead to bugs allowing full control of the Spooler or related print process. Many users don’t understand that print drivers run as SYSTEM which is more powerful than a typical administrator account. So, bugs in drivers are extremely useful for attackers.
In the event a vulnerability is discovered in a driver, Microsoft is dependent on the third-party to update the driver. When publishers no longer exist or consider older products out of support, there is no clear way to address the vulnerability.
IPP Basics
Internet Printing Protocol (IPP) is an HTTP-based protocol and supports many of the authentication methods one would expect from HTTP. Each IPP request is an HTTP POST message, and printers are identified using URI’s such as ipps://printer.example.com/ipp/print. IPP supports all the common operations one would expect from a printer.
Driverless printing supports a limited number of Printer Document Languages (PDL) based on public standards such as PWG Raster and PDF. This limits the unique number of formats the operating system must handle for conversion and greatly simplifies code. Client-side rendering is used to generate the final document sent to the printer.
Unlike LPR/LPD, IPP supports built-in encryption. This support is like the encryption used today when using HTTPS over the web. Access control and authentication are also part of the protocol. Although not intended as a security benefit, the IPP Driverless specifications support a small number of PDLs, limiting the amount of complex parsing required by the client. Today, drivers implement over 40 different PDL’s, which can result in vulnerabilities.
State of IPP Printing in Windows Today
The Windows Print Team has been working to bring IPP printing to more users for some time now. Today, if you view any of our print documentation, you are presented with a notice.
This notice is intended to encourage users to switch to IPP, when possible, and encourage industry partners to switch to IPP-based printing. There will be cases when custom functionality is needed, and vendors can extend support by creating a Print Support App (PSA). IPP Printing in Windows today works side-by-side with driver-based printing, allowing users to choose either configuration. Let’s discuss some of the components of the IPP Print system and the security advantages and disadvantages.
Print Support App (PSA)
PSAs allow printer OEMs and IHVs to extend our existing IPP support for their specific needs. Not all printers support the same features and configuration options. PSAs allow for tailored user experiences without compromising the experience users expect.
These applications take advantage of the Universal Windows Application Platform (UWP), which are more restricted than Win32 applications. Users have more control over what permissions the application can use, and management of updates is automatic through the Microsoft store. Windows will automatically install the correct PSA for users, if one exists, based on the printer’s hardware ID.
Point and Print
Point and Print is a feature that allows users to connect to a remote printer without providing drivers, and has all necessary drivers installed on the client. Point and Print remains with IPP, but it works differently. We no longer must install drivers, but some basic configuration is required to set up the printer. This process works as follows with IPP.
- Windows client and server make a connection over RPC
- Both Server and Client use their inbox Microsoft IPP driver
- Server uses IPP to communicate with Printer
- PSA is installed, if available
Security
IPP-based printing in Windows today removes the need for third-party drivers, and any third-party code installed to support printing runs within an AppContainer, limiting the risk to users. Encryption is supported for all communication, and with a limited number of PDL’s supported, parsing complexity is substantially decreased. This is a meaningful improvement over the model requiring the use of drivers.
However, today, IPP-based printing still runs side-by-side with driver-based Printing. Point and Print, for example, will either install a driver or install an IPP printer in the current configuration, depending on what the server requires. While this approach minimizes compatibility risk, it also greatly limits the changes we can make to improve security.
IPP Printing in Windows today is already a great step forward from a security perspective, and we encourage users to switch whenever possible. We also encourage administrators to prioritize this action across your fleet.
Windows Protected Print Mode (WPP)
WPP builds on the existing IPP print stack where only Mopria certified printers are supported, and disables the ability to load third-party drivers. By doing this, we can make meaningful improvements to print security in Windows that otherwise could not happen. Our goal is to ultimately provide the most secure default configuration and provide the flexibility to revert back to legacy (driver-based) printing at any time, if users find their printer is not compatible.
When users enable WPP mode normal spooler operations are deferred to a new Spooler which implements the WPP improvements. Let’s look at some of those changes.
Limited/Secure Print Configuration
In WPP, many legacy configurations are no longer valid. A common attack on Windows would abuse the fact that a printer port can be a Dynamic Link Library (DLL), and attackers would abuse this to load malicious code. Attackers would also use symbolic links to trick the Spooler into loading malicious code, and that is no longer possible. There are many legacy API’s which are updated to restrict the configuration to values that make sense only when using IPP. This will limit the opportunity for attackers to leverage the Spooler to modify files on the system.
Module Blocking
API’s that allow module loading will be modified to prevent loading of new modules. For example, AddPrintProviderW, and other calls, would result in loading modules which may be malicious. We will also enforce a restriction that ensures that only Microsoft Signed binaries required for IPP are loaded.
Per-User XPS Rendering
XPS rendering will run as the user instead of SYSTEM in WPP. Most print jobs in Windows today involve some XPS conversion and the process that handles this task (PrintFilterPipelineSVC) is the source of many memory corruption vulnerabilities. As with the other issues, by running this process as the user, the impact of these bugs is minimized.
Lower Privileges for Common Spooler tasks
Removing drivers also allows us to take common tasks performed by the Spooler process and move those to a process running as the user. If these processes have memory corruption vulnerability, that impact will be limited to actions only the user can perform.
The new Spooler Worker process has a new restricted token that removes many privileges such as SeTcbPrivilege, SeAssignPrimaryTokenPrivilege and no longer runs at SYSTEM IL.
It does retain SeImpersonatePrivilege which is something we intend to remove in the future.
By removing third-party binaries, we are now able to enable many of the binary mitigations Microsoft has invested in over the years. Processes in WPP will run with many new binary mitigations. Here are some of the highlights:
Control Flow Enforcement Technology (CFG, CET) – Hardware based mitigation which helps to mitigate Return Oriented Programming (ROP) based attacks.
Child Process Creation Disabled – Child process creation will be blocked. This prevents attackers from spawning a new process if they manage to get code execution in the Spooler.
Redirection Guard – prevents many common path redirection attacks which often target the Print Spooler.
Arbitrary Code Guard – prevents dynamic code generation within a process.
These protections make it more difficult to abuse a vulnerability once one is found.
Point and Print
As mentioned above, Point and Print will normally allow driver loading as well as IPP printer configuration. Some users may have an environment with only IPP printers, but malicious attackers can pretend to be a printer and trick users into installing drivers. WPP prevents Point and Print from ever installing third-party drivers, mitigating this risk.
Better Transport Security
Printers make use of a variety of transport protocols and transport encryption is not always used. Often, it is not clear to users if their traffic is encrypted, and determining this can be difficult. IPP supports strong encryption, like what is used by web browsers today. WPP will make it clear to users when their traffic is encrypted and, when possible, encourage users to enable encryption.
Continued Investments to Make Windows Secure by Design
As you can see, moving away from driver-based printing offers many benefits to users and allows Microsoft to make many meaningful improvements to our print system. The existing driver-based system, established decades ago, depends on many third parties and Microsoft all playing their role, which has proven to be too slow for modern threats.
IPP-based printing is well supported, and users who switch will reduce their exposure to attacks. Users who switch to Windows Protected Print Mode will go even further in ensuring they are safe from attackers. WPP is now in Insider builds and we hope you will help us test by trying the feature and providing feedback. Users can enable the feature by following the instructions provided here.
This is an early release; many features are incomplete and subject to change based on feedback. For example, today we lack a UI, and many security improvements are still in progress. Over time these improvements will continue to roll out to Insider Builds as we work to improve WPP.
Also, Windows Protected Print Mode will qualify for the Windows Insider Preview Bounty Program, and we encourage security researchers to identify and report bugs.
Microsoft
