Forem: johnmarion

Microsoft Turns to Modern Print

johnmarion — Sun, 10 May 2026 14:40:03 +0000

In my last article, “Why Microsoft Had to Rethink Printing,” I explained the vulnerabilities introduced by downloading print drivers from a server—commonly associated with the Print Nightmare class of issues. Much of this risk stems from a client model that depends on static configuration files to determine printer capabilities, along with dynamically loaded libraries to process print jobs. Legacy printing methods such as LPR and port 9100 (RAW) rely heavily on vendor-specific components to interpret and render print data. As discussed previously, this model created an attack surface that could allow arbitrary code execution in the SYSTEM context, particularly when using features like “Point and Print.” Beyond security concerns, port 9100 printing simply streams raw bytes to the printer without structure, metadata, or negotiation. This can result in unintended or garbled output—at best a nuisance, at worst a source of confusion during troubleshooting or incident response. Additionally, both LPR and RAW printing lack encryption, making intercepted print data potentially recoverable in transit. In effect, these legacy methods operate as “fire-and-forget” mechanisms, sending data to printers with minimal feedback or control over the outcome. Clearly, more structured print architecture was needed.

To address these limitations, the designers of the Internet Printing Protocol (IPP) in the late 1990s rethought the printing model from the ground up. One of the most significant changes was enabling printers to describe their capabilities dynamically in a standardized, structured format. This eliminated the need for clients to rely on static, model-specific configuration files.
Equally important was the introduction of a formal request/response protocol built on top of HTTP. IPP operations are encapsulated within the body of HTTP requests, allowing the protocol to leverage an existing, robust transport mechanism. This design decision was key to the eventual adoption of the protocol. By using HTTP, IPP gained immediate compatibility with common network infrastructure such as firewalls, proxies, and routing systems, avoiding the need for custom port configurations similar to those required for port 9100 printing.

Moreover, HTTP provides a mature framework for secure communication. With IPPS (IPP over HTTPS), encryption, authentication, and data integrity are handled through established TLS mechanisms rather than proprietary solutions. This not only improved security but also simplified implementation and interoperability across platforms.

The structured nature of IPP also enabled richer interaction between client and printer. Instead of sending an arbitrary byte stream and relying on the printer to infer intent, the client explicitly declared the operation, document format (via MIME type), and job parameters before submission. This allowed for more precise control and predictability in print operations.
At the core of IPP is the ability for clients to query printer capabilities dynamically using the Get-Printer-Attributes operation. This is one of several standard operations defined by the protocol, including Print-Job, Validate-Job, Create-Job, Send-Document, Cancel-Job, and Get-Job-Attributes. These operations form a structured, transactional model for managing print jobs.

An IPP message, when encapsulated within an HTTP request, is represented as a sequence of bytes encoded according to the IPP specification. This encoding defines how operations, attributes, and values are structured and interpreted. Unlike legacy methods, the printer does not attempt to infer the Page Description Language (PDL) from raw data. Instead, the client specifies the document format explicitly using a MIME type, ensuring that the printer processes the job correctly. This distinction has important implications, particularly for environments such as mainframe printing to terminal emulators using Windows pass-through mechanisms, which will be discussed later. Some common attributes that an IPP printer may expose via Get-Printer-Attributes include:

printer-state
ipp-versions-supported
document-formats-supported
document-format-preferred
queued-job-count
printer-resolution-default
output-bin-default
print-scaling-supported
orientation-requested
sides-default
printer-resolution-supported
media-type-supported
paper-kind
paper-input-tray

These attributes allow the client to dynamically determine the printer’s capabilities and configure print jobs accordingly, eliminating the need for static configuration files.

To submit a print job, a client typically uses the Print-Job operation, specifying the target printer, source document, MIME type, and relevant job parameters. The printer returns a job ID that can be used for monitoring and control. However, because Print-Job may begin processing immediately, the job could be completed before the client had an opportunity to act on it. To address this, IPP also supports a more controlled workflow using Create-Job followed by Send-Document. This approach allows the client to obtain a job ID before printing begins, enabling actions such as validation or cancellation prior to execution. Importantly, job control operations in IPP are executed on the printer itself, not just within the client’s print queue. This avoids scenarios common in Windows environments where a job canceled locally may still print because it has already been stored in the printer’s memory.

The structured request/response model of IPP provides additional operational benefits. Because printing only begins after valid operations are processed, intermittent or malformed data sent to the IPP/IPPS port (typically TCP 631) does not result in unintended output. This prevents issues such as random pages being printed due to network scans or port probes—an all-too-common occurrence with port 9100 printers.

A key advantage of IPP over HTTP (IPPS) is that it leverages the existing web infrastructure. Instead of defining a custom TCP port like 9100, the printer exposes a standard HTTP(S) endpoint, so clients only need a URL. This simplifies setup and allows printing to benefit from existing network capabilities like TLS security, authentication, proxy traversal, and standardized addressing. With raw printing over port 9100 (often called “Jet Direct” or “RAW”), Windows has to treat the printer like a generic TCP endpoint. That means manually defining a port, worrying about port numbers, and sometimes dealing with driver quirks. Additionally, HTTP is inspectable and well understood. Tools like curl or browser-based diagnostics can interact with endpoints, which makes troubleshooting issues much easier than with legacy print protocols.

Additionally, IPPS (IPP over HTTPS) enables encrypted transport without additional protocol complexity. In an era where data security is critical, this is a significant advantage. While TLS typically requires the client to trust the printer’s certificate authority, in practice, Windows often allows IPP/IPPS printer installation without strict enforcement of certificate validation, simplifying deployment in many environments.

Microsoft termed the new print architecture “Modern Print” – however this is not a simple marketing ploy. Printers are required to be Mopria compliant, meaning they are certified to promote consistent and reliable printing experience across different brands and models. Mopria certified devices can print from Android devices and Windows 10/11 computers without needing to install additional drivers or software. This is accomplished by supporting a common set of Page Description Languages, allowing the devices to interpret and render print jobs consistently, regardless of the manufacturer. When paired with IPP/IPPS, this experience offers true driver independence and a substantially less complex and more robust print experience than the existing Microsoft print architecture.

Finally, in response to the widespread concerns created by the “Print Nightmare’ vulnerabilities. Microsoft suggests clients implement a security focused feature called Windows Protected Print (WPP). This feature requires implementation of IPP (and more specifically IPPS) as it narrows what the spooler service accepts as legitimate print functionality. Specifically, WPP restricts the types of print drivers and protocols that can interact with the spooler, reducing the attack surface for potential exploits. This approach is designed to limit or mitigate vulnerable functionality and limits the spooler's exposure to only trusted and secure printing operations. Once enforced, older type 3 driver technology, legacy print components, and legacy print protocols such as port 9100 and LPR will no longer function. Implemented with IPPS, a transformation from legacy print to a more secure, robust, interoperable, and user-friendly print subsystem in Windows can be realized. This is the classic win-win scenario for the Windows ecosystem and enterprises that employ them.

Further Reading
For readers who want a deeper understanding of Windows printing architecture—both legacy and modern—consider:

Adopting Internet Printing Protocol for Windows

This book provides a comprehensive exploration of the Windows print subsystem, from driver architecture to network printing protocols, making it a valuable reference for engineers and system administrators.

Coming Next
In the next article, we’ll take a deeper look at some of the implementation issues enterprises may encounter when transitioning to Modern Print.

Why Microsoft Had to Rethink Printing

johnmarion — Tue, 28 Apr 2026 23:34:47 +0000

In the first article, I explored the legacy Microsoft print subsystem and how it worked. In this article, we’ll examine why Microsoft ultimately had to move away from it.

Printers are among the least scrutinized devices on corporate networks—yet they often run full operating systems, store sensitive data, and accept unauthenticated input from across the network. This combination makes them an attractive and often overlooked target for attackers.
Modern office printers are far more than simple output devices. Alongside electro-mechanical components such as motors, lasers, and paper handling systems, they include network interfaces, USB ports, multi-core processors, and onboard storage. Each device runs firmware and embedded operating systems that are just as susceptible to vulnerabilities as traditional endpoints. As a result, printers can serve as a quiet but effective entry point into enterprise environments.

Exploiting Port 9100

One of the most widely used legacy printing methods relies on TCP port 9100 (often referred to as “RAW” printing). Its strength lies in its simplicity: any data sent to the port is treated as print-ready and processed immediately.
To see this behavior in action, enter the following into your browser:

http://:9100

For example: http://printer40:9100

Your browser will attempt to connect but display no meaningful content. When you cancel the request, many printers will interpret the partial HTTP request as printable data and produce a page of output.
While this may seem harmless, it illustrates a fundamental issue: port 9100 provides no authentication, validation, or protocol-level safeguards. Any system with network access to the printer can submit arbitrary data.
In large environments, routine security scans often trigger unintended print jobs, resulting in wasted paper and user confusion. More importantly, this behavior exposes a far more serious risk—attackers can inject arbitrary print streams into devices at will. Given that printer languages such as PCL and PostScript are effectively programmable, this creates a direct and largely unprotected input channel into the device.

Exploiting Point and Print

In the first article, we discussed the convenience of Microsoft’s Point and Print architecture. This model allowed users to connect to shared printers and automatically download and install the required drivers—without needing administrative privileges.
This convenience came at a cost.
The Windows Print Spooler service, which facilitates this process, runs in the SYSTEM security context. It performs privileged operations—such as downloading driver packages and loading associated components—on behalf of the user.
This effectively turned print servers into trusted code distribution mechanisms operating with full system privileges.
If an attacker could manipulate this process, they could execute arbitrary code in the SYSTEM context—one of the most powerful privilege levels in Windows.
This risk became reality with PrintNightmare, a vulnerability that enabled remote code execution through the spooler service.
Point and Print relies on driver packages that include binaries, configuration files, and supporting components. Particularly valuable targets were DLLs referenced in INF files—such as print processors, rendering modules, and port monitors. These components are loaded directly by the spooler service, inheriting its SYSTEM-level privileges.
Although driver packages were expected to be signed, enforcement was inconsistent. Not all referenced DLLs were individually validated at load time, and attackers could exploit this by placing malicious components in locations that the spooler trusted.
To mitigate these risks, Microsoft introduced security updates in mid-2021. By default, administrator privileges are now required to install or update printer drivers via Point and Print. While administrators can configure trusted print servers to restore some of the previous convenience, doing so reintroduces elements of the original risk.

Transport Vulnerabilities

Legacy printing protocols such as port 9100 and LPR transmit data in cleartext. In environments where an attacker gains network visibility—whether through a compromised endpoint or misconfiguration—print jobs can be intercepted and read.
This is more than a theoretical concern. Print jobs frequently contain sensitive information, including financial documents, legal materials, and medical records. Unencrypted transmission of this data represents both a security risk and a potential compliance issue.
Despite widespread adoption of encryption for web and application traffic, print infrastructure has often lagged behind. The result is a significant blind spot: sensitive data is protected in transit across most systems, but not when it is sent to the printer.

Microsoft Turns to IPP/IPPS

Faced with these challenges—unauthenticated input channels, privileged driver execution paths, and unencrypted transport—Microsoft needed a more secure and modern approach to printing.
The Internet Printing Protocol (IPP), and particularly its encrypted variant IPPS, provides a foundation for addressing many of these issues. Unlike legacy approaches, IPP is a full-featured protocol that includes structured requests, defined operations, and support for secure transport.
When combined with standards such as Mopria and IPP Everywhere, IPP enables a driverless or minimally driver-dependent printing model. This reduces reliance on complex, vendor-specific driver packages and eliminates many of the risks associated with them.
In the next article, we’ll explore how Microsoft’s Modern Print architecture leverages IPP to address these longstanding challenges and what that means for enterprise environments.

Further Reading

For readers who want a deeper understanding of Windows printing architecture—both legacy and modern—consider:

Adopting Internet Printing Protocol for Windows
https://link.springer.com/book/10.1007/979-8-8688-2010-6

Coming Next

In the next article, we’ll take a deeper look at Microsoft’s Modern Print initiative and examine how IPP fundamentally changes the printing model—improving security, simplifying deployment, and reducing operational risk.

Understanding Windows Printing: From Legacy to Modern IPP

johnmarion — Tue, 28 Apr 2026 23:21:35 +0000

Network printing often feels like a “black box” to IT professionals. Jobs vanish, printers jam, and support tickets pile up. For engineers and system administrators, this lack of visibility can create serious headaches when changes are made to print infrastructure. Microsoft has been quietly evolving its printing architecture, and enterprises that don’t understand these changes may face unexpected issues.

This article is the first in a series exploring Windows’ adoption of IPP/IPPS and the transition from legacy printing systems to what Microsoft now calls “Modern Print.” Here, we’ll focus on the foundations: how legacy Windows printing worked, why it persisted for so long, and what limitations prompted change.

Legacy vs. Modern Printing

For clarity, this article will refer to older Windows printing systems as “legacy print” and Microsoft’s newest print initiative as “Modern Print.” Modern Print includes support for IPP (Internet Printing Protocol), which has been around since 1996. By 1999, IPP had become the standard network printing protocol for Linux through CUPS (Common Unix Printing System).
You might wonder why Microsoft held onto its legacy system for so long. To answer that, we need to understand how Windows printing worked and where its weaknesses lay.

How Printing Works: The Role of Page Description Languages (PDLs)

All print systems share a common goal: to faithfully reproduce the layout of text and graphics from one device (like your monitor) to another (your printer). This requires a Page Description Language (PDL)—software instructions that describe the page layout in computer memory.
If both the computer and printer interpret the same PDL, the printed output matches what you see on screen. The most common PDLs today are:

• PCL (Print Control Language): Fast and lightweight, suitable for general office printing.
• PostScript (PS): Vector-based, ideal for graphics-heavy documents.
• PDF (Portable Document Format): Highly portable and consistent across devices.

Before printing, the computer must know the printer’s capabilities—fonts, page sizes, duplexing, and more. Designing a complex document for a printer that cannot handle it is a recipe for failure.

Drivers: The Bridge Between Computer and Printer

In legacy Windows printing, a printer driver communicated the printer’s capabilities to the computer. Despite the name, a driver is actually a collection of configuration files and libraries responsible for:

• Formatting print data
• Handling print job status
• Interfacing with the print spooler
• Sending data to the correct port

Over the years, the growing diversity of printers created a massive driver ecosystem. Users sometimes installed the wrong driver—or failed to update it—causing printing errors.

To simplify this, Microsoft introduced the UniDriver architecture. Here, Microsoft wrote the core functionality (PCL or PS), while vendors supplied device-specific information through GPD (Generic Printer Description) or PPD (PostScript Printer Description) files. Essentially, these files answer the question:

“How does the computer know what the printer can actually do?”
Vendors could add new printers by updating these small text files, reducing complexity and improving compatibility.

Sending the Print Job: Protocols and Ports

Once a print job is composed, it must be transmitted to the printer. In home setups, this is usually via USB. On corporate networks, jobs often traverse TCP/IP connections.
Windows supports several print protocols, but the most widely used is Port 9100 printing, which sends data directly from client to printer over TCP. It’s popular because it:

• Provides low latency and high speed
• Supports bidirectional communication (with additional libraries)

Other protocols, like Line Printer Daemon (LPR), were more common in Unix environments. In the PC world, Port 9100 became the standard.

Print Servers and “Point and Print”

In corporate environments, multiple users often share a single printer. Enter the print server, which queues jobs to prevent printers from being overwhelmed and allows centralized administration.
Microsoft’s Point and Print feature simplifies deployment further. Clients connecting to a shared printer automatically download the necessary drivers from the print server, even without special privileges. This makes large-scale printer management much easier—but it also introduces potential security concerns if drivers are not carefully managed.

Legacy Print: Strengths and Limitations

Legacy Windows printing worked reasonably well, enabling convenient printer pooling and basic network print management. However, it had notable limitations:

• Complex driver management
• Risk of incompatible or outdated drivers
• Limited visibility into network print jobs and protocols

These challenges set the stage for Microsoft’s adoption of IPP and Modern Print—a transition that promises to simplify administration, improve standardization, and enhance reliability. Understanding the legacy architecture is critical before moving forward with these modern systems.

Further Reading

For readers who want a deeper understanding of Windows printing architecture, including both legacy and modern systems, consider:

Adopting Internet Printing Protocol for Windows

https://link.springer.com/book/10.1007/979-8-8688-2010-6

– This book provides a comprehensive exploration of the Windows print subsystem, from driver architecture to network printing protocols, making it a valuable reference for engineers and system administrators.

Coming Next: Over the next few article(s), we’ll explore Microsoft’s Modern Print initiative in detail, examining how IPP adoption addresses the limitations of legacy printing and what IT teams need to know to prepare their networks