Foomatic-Rip rejects unknown values
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.
Summary
The filter foomatic-rip will reject any values of PPD options FoomaticRIPCommandLine, FoomaticRIPCommandLinePDF, and FoomaticRIPOptionSetting. Users are able to scan drivers of their installed printers by the tool foomatic-hash, which outputs a file which is used for allowing the found values for the filter.
Owner
- Name: Zdenek Dohnal
- Email: zdohnal@redhat.com
Detailed Description
The filter foomatic-rip supports several PPD options which are used to construct a shell command, which is to be run in a new process. Those options are FoomaticRIPCommandLine, FoomaticRIPCommandLinePDF, and FoomaticRIPOptionSettings. This behavior was implemented around 20 years ago to help printer vendors or enthusiasts with writing printer drivers for Linux. Driver creators did not have to write a new filter which would apply requested changes into a filtered file, but wrote set of shell commands, Postscript code or Perl code which were applied to the print job before sending it to the printer.
However this approach is often the final goal of attackers, who exploit another security vulnerabilities in the printing stack to get users to install and use a malicious PPD file for their printer, which will contain crafted mentioned PPD options. Such issues are mitigated by foomatic-rip being run under user lp in the default configuration.
To prevent unintentional use of malicious foomatic-related PPD options, the filter wonât accept any values by default. As a way how to review and create an allowed list of safe values, the tool foomatic-hash is implemented.
The tool foomatic-hash scans a PPD file or a path with drivers defined on its command line and outputs two files - one with found values for users to review, and the other with the found values hashed and ready to be copied into directories where foomatic-rip reads them.
In new Fedora 43 installations users are expected to run foomatic-hash tool, review the scan findings and allow the found values by moving the file with hashes into the directory /etc/foomatic/hashes.d.
Feedback
- Will we allow every foomatic-related PPD options values which are already in Fedora?
Since foomatic-rip is mostly used with older printers or with printers which have another support alternative (like AirPrint), and there are many such older drivers for printers which are now not used often, there would be many values to review for printing stack maintainers in comparison to additional value it gains for Fedora. However the package cups-filters provides a directory which is read by foomatic-rip in case a printer driver wants to review and ship allowed hashes. The directory /usr/share/foomatic/hashes.d is present for this purpose and developers can install their files with allowed hashes into this directory.
- Will the previously installed print queue be working after upgrade?
Based on this feedback the proposal owner will implement a RPM scriptlet which will allow values from installed printers, which were installed in the previous Fedora version. A message will be generated during DNF upgrade if there are print queues with such drivers, and direct user to foomatic-rip man page.
- Is it possible to sanitize the values instead of introducing reject/allow mechanism?
Unfortunately this is not possible due functionality of those options. They were meant to construct a shell command, so we cannot forbid interpreter calls or remove/escape special characters since it would break the correct shell command.
Benefit to Fedora
The change improves Fedora security while leaving a way for users who depend on the driver with the filter foomatic-rip to allow their drivers.
Scope
- Proposal owners:
Proposal owner will apply the upstream patch implementing the issue, and test upgrade path.
- Other developers:
(optional) Printer driver maintainers might scan drivers provided by their package, review the findings and if there is no discrepancies, ship the file with hashed values at directory /usr/share/foomatic/hashes.d.
-
Release engineering: N/A
-
Policies and guidelines: N/A (not needed for this Change)
-
Trademark approval: N/A (not needed for this Change)
-
Alignment with the Fedora Strategy:
Upgrade/compatibility impact
Upgrade from Fedora 42 to Fedora 43 will allow the values of already installed printers to maintain functionality, but users are expected to review the file with found values. The file with findings will be present in the directory /var/tmp in the file with prefix foomatic-scan.
How To Test
How to find out if drivers with foomatic-rip are used with the currently installed printers:
$ sudo grep -Rn âFoomaticRIPCommandLine|FoomaticRIPCommandLinePDF|FoomaticRIPOptionSettingâ /etc/cups/ppd /etc/cups/ppd/ricoh.ppd:52:*FoomaticRIPCommandLine: "printf "%%!PS-Adobe-3.0 /etc/cups/ppd/ricoh.ppd:759:*RIPostScript IRIPS/PostScript Emulation: â%% FoomaticRIPOptionSetting: RIPostScript=IRIPSâ /etc/cups/ppd/ricoh.ppd:760:*FoomaticRIPOptionSetting RIPostScript=IRIPS: "/isGenuine{\n&& âŠ
In the example, the print queue called ricoh uses the affected PPD options.
If its values are not allowed, the following situation will happen:
$ lp -d ricoh /etc/fstab $ journalctl -u cups -r ⊠Job stopped due to filter errors; please consult the syslog file for details. âŠ
If CUPS debug logs are enabled, there is a specific message in the journal:
$ journalctl -u cups -r ⊠Process is dying with "ERROR: The value of the key FoomaticRIPCommandLine is not among the allowed values - see foomatic-rip man page for more instructions. âŠ
User is expected to run foomatic-hash, to review the scan result in file_to_review, and if the found values do not look malicious or the user accepts them, to copy them into the directory /etc/foomatic/hashes.d:
$ sudo foomatic-hash --ppd-paths /etc/cups/ppd file_to_review local_hashes $ sudo cp local_hashes /etc/foomatic/hashes.h $ lp -d ricoh /etc/fstab (Print job succeeds)
User Experience
Users with new Fedora 43 installations will have to allow FoomaticRip values their drivers use after printer installation.
Steps:
$ sudo foomatic-hash --ppd-paths /etc/cups/ppd file_to_review local_hashes $ sudo cp local_hashes /etc/foomatic/hashes.h
Users who upgrade to Fedora 43 are expected to review the found values from their installed printers after upgrade - the file with findings will be present in the directory /var/tmp in the file with prefix foomatic-scan.
In case a malicious or a suspicious value is found, users can find the driver with the value in the directory /etc/cups/ppd. There the driver file is called <printer_name>.ppd, where <printer_name> is the name of a specific printer user has installed. Users are encouraged to reinstall the printer with a different compatible driver or delete such printer.
Dependencies
(optional) Printer driver packages which use foomatic-rip - e.g. hplip, foomatic-db, ptouch-driver, foo2zjs - in case their maintainers are willing to scan their drivers, review findings and ship the hashes in Fedora.
Contingency Plan
- Contingency mechanism: (What to do? Who will do it?) The upstream patch wonât be applied in cups-filters
- Contingency deadline: Beta Freeze
- Blocks release? No
Documentation
N/A (not a System Wide Change)
Release Notes
Foomatic-Rip filter rejects values of PPD options FoomaticRipCommandLine, FoomaticRipCommandLinePDF, and FoomaticRipOptionSetting which are not allowed in configuration on new Fedora installations by default. Users are expected to run the tool foomatic-hash, review its findings and if they approve the findings are not malicious, allow the values by moving the file with hashes into /etc/foomatic/hashes.d. See man foomatic-rip and man foomatic-hash for more info.
Last edited by @amoloney 2025-07-24T17:01:20Z
Last edited by @amoloney 2025-07-24T17:01:20Z
instead of reiterating. You can even do this by email, by replying with the heart emoji or just â+1â. This will make long topics easier to follow.