SecureDrop serves as a tips entry point for news organizations, often with a small set of journalists reviewing incoming submissions and distributing them to the rest of the newsroom. The next-generation SecureDrop Workstation supports conveniently exporting submissions to encrypted USB drives and USB-connected printers.

But printing carries a bad legacy of never simply working, no matter the operating system. This was very much the case on the SecureDrop Workstation, which is why the SecureDrop team had automated printer driver installation so that the users didn’t have to do this themselves. However, this had one critical disadvantage: it only works for the printers we added support for, and therefore this number was extremely low: only two supported printers. So a better solution was needed.

To add some extra urgency, our logs had been warning us that CUPS 3.0 will no longer support, by default, the way we were configuring printers (manually adding printer drivers), with an expected release timeline of mid-2025.

With the recent SecureDrop Workstation 1.2.0 release, we have moved into a “just works” approach, expanding the number of officially supported printers to potentially thousands of easily procurable printers. This blog post describes how we did it from a technical standpoint.

For a file to be printed, the computer first needs to know how to communicate that document to the printer. This piece of software is generally known as a driver. For printers on Linux, typically these were individual .ppd files, often provided by the printer vendor or shipped by various Linux distributions.

As alluded to earlier, we are particularly concerned with USB-connected printers.

There are multiple ways to configure a printer, none of which are particularly user-friendly:

• Path 1: via a web browser,
• Path 2: via the command line
• Path 3: via the printer configuration program system-config-printer.

The first two require manual selection of the specific printer driver for the selected printer, while system-config-printer has some functionality to guess the printer driver. But no matter the approach, some level of manual configuration or automation is necessary.

To add some more complexity to the mix, the SecureDrop Workstation’s printing component lives on a disposable virtual machine (sd-devices), to mitigate malware persistence risks. So even if we enabled users to manually add their printers, it would be reset after the computer was restarted.

To work around this, we automated setting up the printer configuration right as a file was being printed. Adding persistence to enable the configuration of other printers would carry its own risks, and given that this virtual machine already deals with potentially malicious files, this was a risk not worth taking.

If only there were printers that could automatically have their drivers set up.

The alternative to printer drivers turns out to be “driverless”. It’s a set of essentially equivalent standards (Apple AirPrint, IPP Everywhere, Mopria) that define how to expose which functionalities printers have available, what file types they support, and other information. This server (which we’ll later refer as IPP server) is typically reachable on the local network and from its information, our computer is then able to build a PPD printer driver “dynamically” to fully make use of its features — all of this without the need for user interaction or manual setup.

This is what it looks like from the user’s perspective:

1. The user wants to print a file and opens a print dialog
2. The user plugs the printer for the first time
3. The printer appears in the printers list
4. After a few seconds, while it is loading the printer capabilities for the first time, all printer options become available.
5. Print!

This is significantly less involved than having to configure the printer, as we described in the previous section. And if you’re looking for what happens under the hood, OpenPrinting has a nice overview.

Another thing to consider in the implementation is that driverless printing seems to be primarily designed for networked printers. While we recognize that the printer market is shifting away from USB-based printing, the SecureDrop Workstation is all about preventing exfiltration risks and a networked printer opens up significantly more risks.

Fortunately, it turns out that driverless printing via USB-only printers is still possible. A component called IPP-over-USB makes the bridge between the printer and the computer by creating a reverse proxy so that the printer shows as if it were a networked device.

With this last piece, all the components are in line for the complete deprecation of classic PPD drivers.

All in all, adapting to driverless printing was relatively easy to implement. For our Debian-based virtual machine, all we needed was to add a couple of dependencies: cups (which we already had), avahi-daemon and ipp-usb.

When a user plugs in a USB printer, IPP-USB does its job of exposing the IPP server locally, and the socket-activated avahi-daemon discovers the printer. The last part was to have an IPP-compatible print dialog (more on that later).

This implementation also led to a significant amount of code simplification once we decided to fully drop support for legacy printer drivers. This boiled down to a few things:

1. No longer needing to handle the printer driver installation, which removed all the automated printer detection and respective driver installation.
2. Delegating printer troubleshooting to the system itself. Printing to a driverless printer brings up a convenient tray menu item to check on printing progress, accompanied by print-related notifications that inform the user if there’s missing paper, ink, or other potential issues.

We did however, have to replace the incredibly old “X Printing Panel” print dialog we had been using. This was an overdue change, created even before knowing we needed to switch to driverless printing, but it complemented this release nicely and was necessary to take advantage of dynamic print queues and surfacing printer status information on the dialog itself.

We settled on using a GTK-based print dialog, given that we could not find any established project that provided an out-of-the-box print dialog that “just worked.” More on that in a future blog post.

Dynamic printer driver construction is naturally prone to injection attacks as it relies on printer-provided information to construct a driver. This was made evident in 2024 by critical CUPS vulnerabilities. Even though after some communication challenges the issue was fixed, the fundamental propensity for this kind of vulnerability still exists, and other issues exist with the code, as the author highlights. It is not an ideal situation, but the project was already heavily relying on CUPS as the de facto standard for UNIX printing.

As far as the threat model is concerned, not much changes. The main factor to mitigate continues to be malicious data submitted by anonymous adversaries pretending to be sources, and the change in print approach does not change much. Dynamic driver construction does potentially increase the attack surface, assuming the printer is attacker-controlled, but there were already risks associated with using USB devices in the first place.

Another attack vector we considered in the evaluation was the fact that USB devices used for exporting documents could also pretend to be printers. In a simpler attack, the device would pretend to be a printer without any further exploitation. It would present as an IPP-USB-capable device and show up, tricking users into thinking it is a legitimate printer. The malicious device would then have access to the document for exfiltration. The more malicious version of this would be a USB device that not only pretends to be a printer but also attempts to gain code execution through driverless printing. In this case, the attacker could exfiltrate onto the malicious USB all documents attempted to be exported until the device is restarted.

These attack scenarios are not unreasonable, and we do advise newsrooms to consider targeted hardware supply chain attacks, but we ultimately concluded exporting via USB devices already presents a relatively large attack surface, and driverless printing only adds one more way to take advantage of it.

Currently, the main lines of defense are (1) the lack of persistence and (2) the air gap in USB-exposed virtual machines (sd-devices and sys-usb) and printers themselves. Regarding (1), the lack of persistence makes any malicious execution (assuming Qubes’ security principles hold) only able to capture documents exported for the duration of the session while the device is plugged in. In an ideal scenario, the printer would also have no persistence. But we believe we’re probably far away from an open hardware Tails-inspired amnesiac printer. Regarding (2), the virtual air gap helps mitigate exfiltration vectors in case malware is ever executed on these virtual machines.

In the future, we’d like to have alternatives to USB exporting, like sharing to Signal and automatic Dangerzone integration.

As with most impending breaking changes, the need to adapt to more modern standards in an area that doesn’t always have much priority (printing) always leads to resistance, especially if things are not broken. The fact that printing has a bad reputation regarding a constant need for troubleshooting does not make this resistance any easier.

This change, however, brought some additional security challenges to the mix. As a security-focused project that takes advantage of Qubes OS’ compartmentalization approach, we believe our current mitigation strategies sufficiently address some of the fundamental vulnerabilities driverless printing brings to the mix. But we are also looking forward to providing users with non-USB ways of exporting documents out of the workstation.

In spite of this, we managed to change our printing implementation months before CUPS 3.0 was released and were pleasantly surprised by how much better it made the printing experience from what we’ve seen so far. It will take some time for us to get actual user feedback, but we can confidently say that it changed our outlook on printing for the better.