cups, cups-filters and libppd security issues

A series of vulnerabilities have been found in cups-browsed and cups-filters allowing for unauthenticated remote code execution.

The upstream advisories are

The write-up from the security researcher that reported the issues: Attacking UNIX systems via CUPS, Part I.

This post serves as a way to inform the community about our progress on mitigating and fixing the issues.

Am I affected?

You are affected, if you have enabled both cups and Avahi in your NixOS configuration through:

  • services.printing.enable
  • services.avahi.enable

You can quickly check if cups-browsed is enabled with systemctl is-enabled cups-browsed.service.

Workaround

Disable browsed entirely through its avahi dependency

If it is acceptable in your environment, you can disable services.avahi.enable which will disable the cups-browsed service entirely.

Disable the browsed systemd service

If you need to keep Avahi, you can disable the cups-browsed systemd service specifically with:

systemd.services.cups-browsed = {
  enable = false;
  unitConfig.Mask = true;
}

A new option has also been added to control browsed independently from Avahi: services.printing.browsed.enable. The option might not yet be available in your situation, see:

Patches

For CVE-2024-47076 in libcupsfilters:

For CVE-2024-47175 in libppd:

13 Likes

For those in a hurry: you can quickly check whether a host is affected with systemctl is-enabled cups-browsed.service. If not found, you’re good.

Further TL;DR;: there are two entry points to target this service: a direct one when UDP port 631 is exposed, and an indirect one by spoofing discovery/advertisement. Having cups-browsed behind a firewall is therefore not enough to be safe due to that second path.

A base configuration on NixOS with just CUPS (services.printing.enable alone) is not affected.

(Those are my quick notes, please correct if wrong.)

6 Likes