[DanMcInerney]

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.

[btown]

If you're vulnerable to attacks from the LAN, you're vulnerable to your wi-fi router (or your coffee shop/workplace's router) being compromised, which is quite common; see e.g. https://www.bleepingcomputer.com/news/security/mirai-botnet-... and https://blog.lumen.com/the-pumpkin-eclipse/

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!

[runjake]

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.

[btown]

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.

[runjake]

FWIW, my team is me and maaaybe 30% of another guy, but point noted. :-)

[graemep]

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.

[tsimionescu]

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.

[gordonfish]

This is why on public servers I block everything inbound and only allow specific needed services through.

[bongodongobob]

Who doesn't block all unneeded ports on an internet facing server or have it behind a firewall of some sort?

[bshipp]

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.

[bongodongobob]

Well lots of people crash 600HP cars right after they buy them. If you haven't done your homework, you'll learn quickly.

[bshipp]

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.

[bongodongobob]

You don't need to read CVEs to turn on your fucking firewall. It's in every single how to set up a server for dummies tutorial I've ever seen.

[sgc]

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.

Sent from my Ubuntu laptop.

[eikenberry]

Which distro do you see Cups listening on 0.0.0.0? On Debian (at least, only one I have handy) it only listens on localhost.

[edit: I was wrong, it listens on 0.0.0.0 for UDP. I was only checking TCP. ]

[mikepavone]

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

[raverbashing]

Why does it even listens in UDP at this day and age?!

[mikepavone]

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.

[ahoka]

DNS is actually UDP/TCP. It’s probably required for receiving unicast messages, if it’s using DNS-SD

[yrro]

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.

[ahoka]

To receive multicast messages, probably.

[bonzini]

OpenSUSE

But it looks like cups-browsed is only needed on the Internet; locally you only need mDNS.

[tsimionescu]

mDNS doesn't allow the printer to register itself to your system, which is the (highly dubious!) purpose of cups-browsed.

[yrro]

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.

[rini17]

MX Linux

[cp9]

on popOS I see 0.0.0.0:*

I'm not sure why it deviates from Debian and Ubuntu which its based on though

[jeffbee]

That's the wrong column of netstat output, I think. "0.0.0.0:*" stands in for the (non-existent) peer address of a listening port.

[cp9]

oh sorry yeah I copied the wrong column. the correct column is `0.0.0.0:631`

[RGBCube]

I'm pretty sure all major distros configure it to listen locally instead.

[mikepavone]

cupsd is configured to listen locally, but cups-browsed has to listen on the network to do its job (network printer auto-discovery)

[gordonfish]

> but cups-browsed has to listen on the network to do its job (network printer auto-discovery)

Isn't listening on 0.0.0.0 instead of localhost only needed if the machine itself is hosting a printer that needs to be accessible to other hosts?

[mikepavone]

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).

EDIT: Here's a description of the protocol in question: https://opensource.apple.com/source/cups/cups-327/cups/doc/h...

[tsimionescu]

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.