It appears that the vulnerable service in question listens on 0.0.0.0 which is concerning, it means attacks from the LAN are vulnerable by default and you have to explicitly block port 631 if the server is exposed to internet. Granted, requires user to print something to trigger which, I mean, I don't think I've printed anything from Linux in my life, but he does claim getting callbacks from 100's of thousands of linux machines which is believable.
Assuming that most routers are silently compromised, with their command-and-control operators just waiting for an exploit like this one, is almost par for the course these days!
The problem: you're thinking in terms of home/small business networks.
The rest of us are thinking in terms of larger networks (in my case with hundreds of subnets and tens of thousands of nodes) where "631 is blocked at the firewall" isn't of much relief. The firewall is merely one, rather easy to get past, barrier. We're also concerned with east/west traffic.
For sure, and sending hug-ops to teams like yours that have to deploy & enforce mass patches! But I'm also thinking of environments that don't even have the benefit of a team like yours. https://issuetracker.google.com/issues/172222838?pli=1 is (or seems to be?) a saving grace, without which every school using Chromebooks could see worms propagating rapidly if even one student connected to a compromised router at home.
Would you also not block this at the firewall on individual nodes: if you block incoming incoming UDP on port 631 that would at least eliminate one of the two entry points, right?
There is no detail in the article about the other.
The port has to be open on the node for the functionality to work - the whole point is that printers on the same LAN can auto-register. If you don't want that, disabling cups-browsed is much safer than just relying on the firewall. If you do want that, you can't firewall the port at all.
I guess the important question is whether or not these things are blocked by default or require user intervention to disable cups? Sure, many of us block all ports by default and either route everything behind a reverse proxy or punch very specific holes in the firewall that we know are there and can monitor, but someone firing up an ubuntu distribution for their first foray into linux is probably not thinking that way.
The people who are crashing their 600HP Linux systems are, unfortunately, not the ones who are reading CVE listings in their spare time. Canonical and other distros are probably going to have to patch that default setting.
There are a lot of comments on here that assume Linux is only for servers. But just recently there was a post on HN indicating Linux will likely hit 5% desktop share for the first time this year. That's a lot of people on Linux - and a far higher percentage of people using Linux on the desktop will not know anything about this. Sane defaults should not be a luxury. Of course people should know to wear their seatbelts, but seatbelt alarms are still a very good thing.
And this is why Microsoft force pushes updates. I think when Linux desktops become really popular there is quite a worry if the users simply do not update them regularly enough. Or if they are not secured in most ways by default.
On my Ubuntu 22.04 machine, cupsd itself is only listening on localhost, but cups-browsed (which is what has the vulnerability here) is listening on 0.0.0.0
I believe it's implementing DNS-SD for network printer auto-discovery. I'm not terribly familiar with DNS-SD, but given that normal DNS is UDP based it would be unsurprising for DNS-SD to also use UDP.
The purpose of cups-browsed is to listen on a UDP port which allows it to receive broadcasts from legacy cups servers on the local network, whereupon it will talk to cups and configure a local print queue for the printers on the discovered server.
A modern setup doesn't need it and doesn't use it.
Modern cups discovered printers via mDNS and does indeed automatically create temporary destinations for them. This only works with "IPP Everywhere" printers which are 'driverless', i.e., the risk of doing this is limited since there's no printer model-specific software that needs to be run on the local machine to print to a remote printer, as opposed to the legacy protocol implemented (apparently unsafely!) by cups-browsed.
I am very unfamiliar with the protocol, but my impression from a little reading is that the sharing computer broadcasts and the receiver listens. This appears to be for some CUPS specific browsing/discovery protocol rather than mDNS/DNS-SD (cups-browsed supports adding printers discovered that way but depends on avahi to handle the mDNS part).
No, per the article, cups-browsed is used so that a printer can register itself to your system. The printer is the one that initiates a connection to tell your system that it is available at some URL.
