The Queues & Drivers section in PaperCut Hive and Pocket provides powerful functionality that manages printer drivers using system privileges. This page describes aspects of the system that have been designed to mitigate potential security issues and misuse.
Printer driver install privileges
Installing printer drivers on Windows and CUPS (macOS and Linux) requires system-level privileges. Therefore, the installation runs from the Edge Node Service, which runs with these privileges.
Note that it’s possible for PaperCut Hive or Pocket administrators to abuse their privilege to deploy printer drivers to systems running the edge node software. It is therefore important to limit admin access to only those who need it, and to protect access to those admin accounts.
Changes must be initiated by admins
Actions that result in a change to the configuration of queues and drivers must be initiated by a PaperCut Hive or Pocket administrator. For example, an edge node in the organization may be requested to upload a driver, but only when initiated by an admin. These admin-initiated actions include:
- uploading a driver
- testing a queue (installing a queue and driver to a specific edge node)
- deploying a queue (installing a queue and driver to all edge nodes).
When clients call into the cloud to check for the current print queues and drivers to download, the state they are receiving is state that has been set by an administrator.
Data storage model
When a print queue is copied (uploaded), it is split into two parts: the print queue configuration part, and the driver part. Uploading occurs from the selected edge node to PaperCut’s cloud. Downloading occurs from PaperCut’s cloud to your edge nodes (and in the future it may also occur between edge nodes). While both parts are stored by PaperCut in the cloud, they are handled differently.
The queue configuration part is considered potentially sensitive. It contains the print queue name, default print settings, and other configuration created by the driver. This part is stored privately to your organization.
The driver part is not sensitive and contains the core of what was downloaded from the manufacturer’s website. This part is stored in a shared repository of drivers. Read on for details about how this is managed.
Driver integrity checking
When an admin has requested that a queue be copied, and the driver part is being prepared for upload, a cryptographic hash of the driver files is taken. This uniquely identifies the driver. If this driver has been uploaded previously, by your organization or another, then it does not need to be uploaded again. This is the same principle used by Git (the version control system) and hash-based file systems.
When the driver part is downloaded, PaperCut Hive or Pocket verifies this hash to ensure it is the same as what the admin requested.
This doesn’t mean that drivers are automatically available to other organizations. A driver is only “unlocked” through the process of copying a queue and discovering its hash. In other words, the system only pastes what you have copied.
It’s important to note that while the system performs integrity checks, it does not vouch for the function of the driver. For this reason, it is important to only upload drivers from trusted systems, such as a system you personally manage, and to obtain them from legitimate manufacturer sources. Otherwise, you run the risk of inadvertently spreading malware between your systems.
Hashing details
The driver part is hashed twice: once using SHA256, and again using MD5.
The MD5 hash is used as a performance optimization for quick hash checking immediately after the file has been uploaded to the cloud, allowing tampered files to be discarded.
The SHA256 hash is validated by each client immediately after downloading the driver part. In this way, even if an attacker was able to cause an MD5 hash collision using tampered content, the content is still protected from running on clients due to the SHA256 hash.
Comments