Please let me know of any other setting that may be helpful, or other approaches to avoiding these issues.
Disable and remove the cups-browsed service if you don’t need it (and probably you don’t).
services.printing.browsed.enable = false;
Update the CUPS package on your systems.
release-24.05 has cups-2.4.8
nixpkgs-unstable & master have cups-2.4.10
I don’t know which versions of the affected packages (cups-browsed, libcupsfilters, libppd, and cups-filters) are included with these versions.
In case your system can’t be updated and for some reason you rely on this service, block all traffic to UDP port 631 and possibly all DNS-SD traffic (good luck if you use zeroconf).
## Don’t know how to ensure that UDP 631 isn’t open.
networking.firewall.enable = true;
Entirely personal recommendation, take it or leave it: I’ve seen and attacked enough of this codebase to remove any CUPS service, binary and library from any of my systems and never again use a UNIX system to print. I’m also removing every zeroconf / avahi / bonjour listener. You might consider doing the same.
services.avahi.enable = false;
services.printing.enable = false;
## These options cause Avahi to be enabled, so either explicitly disable them or you may need to use `mkForce` above.
hardware.pulseaudio.zeroconf.publish.enable = false;
hardware.pulseaudio.zeroconf.discovery.enable = false;
services.gnome.core-shell.enable = false;
services.shairport-sync.enable = false;
## This option causes printing to be enabled, so either explicitly disable it or you may need to use `mkForce` above.
services.printing.cups-pdf.enable = false;
does not exist, but I disabled everything else so it should be fine.
Another few options to take a look at disabling are
# this autostarts CUPS on first incoming connection
services.printing.startWhenNeeded = false;
# this might be what sellout was trying to share idk
# mynixos says that this "Specifies whether shared printers are advertised."
services.printing.browsing = false;
I appreciate that this is well-intentioned, but I don’t find most of these remediations practical, as I rely on network discovery of printers, and use IPP everywhere / airscan for printing/scanning. If there was a viable alternative I’d gladly switch, but “don’t print anymore” is a bit too far.
And using nixpkgs-unstable / release-24.05 would entail using code that has not passed nixos tests, which means risking system stability.
The most realistic remediation I would consider is simply updating cups (which in my case should just be a cherry-pick, but I’ll have to investigate further).
Another few options to take a look at disabling are
# this autostarts CUPS on first incoming connection
services.printing.startWhenNeeded = false;
Oh! It might be good to set this to true rather than disabling printing altogether, since it won’t be running constantly.
# this might be what sellout was trying to share idk
# mynixos says that this "Specifies whether shared printers are advertised."
services.printing.browsing = false;
I think this is unrelated – this is about advertising your printers, whereas browsed is about discovering other printers.
Okay, looking a bit further, the post mentions that all versions up to and including 2.0.1 for cups-filters/browsed are vulnerable. Unfortunately that’s also the last released version of cups, so that effectively means that all releases are affected.
Also, cups-filters in nixpkgs master is on version 1.28.17, indicating that it’s very far from being updated. Hence the only option to get the patch is to actually overlay cups-filters at this time and set patches yourself.
With that said, even the patches don’t seem to cover all the vulns and systems using cups appear to still be insecure
I appreciate that this is well-intentioned, but I don’t find most of these remediations practical, as I rely on network discovery of printers, and use IPP everywhere / airscan for printing/scanning. If there was a viable alternative I’d gladly switch, but “don’t print anymore” is a bit too far.
I agree – I was just trying to provide concrete Nix approaches for the various remediations, so that users can decide which ones work for them. It sounds like services.printing.startWhenNeeded, mentioned by @GildedSeraphim, might help mitigate the issue, since CUPS won’t be running all the time.
Also, this may prompt people to specifically check machines they don’t use for printing, and ensure that they haven’t just inherited general configs that have enabled it.
And using nixpkgs-unstable / release-24.05 would entail using code that has not passed nixos tests, which means risking system stability.
Wait, I didn’t realize this about release-24.05. I had assumed that was the current most-thoroughly-tested branch. Why is it not?
The most realistic remediation I would consider is simply updating cups (which in my case should just be a cherry-pick, but I’ll have to investigate further).
Unfortunately, I don’t think these issues are patched yet. At least GitHub - OpenPrinting/cups-browsed shows the latest release as cups-browsed-2.0.1, which is listed as vulnerable in the announcement. (The vulnerabilities were apparently leaked, so the announcement had to be accelerated.)
Also, one of the CVEs (specifically the one about cups-browsed) has a severity of 9.9 (out of 10) and two others are at 8.6. So not printing for a few days might be worth it.
You confused release-24.05 with nixos-24.05. Never use release-* branches if you want a stable system.
Where did you come up with a “few days” for the estimate?
Numerical ratings are meaningless but reading the writeup it’s arbitrary silent RCE, which is obviously an issue, but again the planned patches don’t cover the full vulnerability space as the writeup mentions.
And they also point out the lack of willingness of the CUPS devs to address security issues.
So practically the choices offered here are “don’t print on unix ever again” or “live with the vuln”.
I don’t particularly like either of those options, so I’ll put forth one of my own: switch distros away from NixOS to one that has Mandatory Access Controls (MAC) to prevent running arbitrary commands in an unauthorised context. (And of course spending the time to write and test said rules properly.)
Has anyone verified that the vulnerability actually allows “running arbitrary commands in an unauthorised context” on NixOS? From glancing at the CUPS config files last night, I hoped that at least they would be confined to the cups user and lp group.
cups-browsed is the entrypoint of exploitation chain so disabling it blocks the known issue.
And yes the option to disable it without touching avahi was introduced very recently
With the default configuration on NixOS cups-browsed does not have cups in the BrowseRemoteProtocols only DNS SD so the (current) public exploit does not work.
