Sent from my Ubuntu laptop.
[edit: I was wrong, it listens on 0.0.0.0 for UDP. I was only checking TCP. ]
A modern setup doesn't need it and doesn't use it.
But it looks like cups-browsed is only needed on the Internet; locally you only need mDNS.
I'm not sure why it deviates from Debian and Ubuntu which its based on though
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?
EDIT: Here's a description of the protocol in question: https://opensource.apple.com/source/cups/cups-327/cups/doc/h...
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 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.
There is no detail in the article about the other.
Hyped it up to be some massive thing but it turned out to be a massive nothingbuger for me at least
I can think of another reason they got patronised.
>A remote unauthenticated attacker can silently replace existing printers’ (or install new ones) IPP urls with a malicious one, resulting in arbitrary command execution (on the computer) when a print job is started (from that computer).
>WAN / public internet: a remote attacker sends an UDP packet to port 631. No authentication whatsoever.
>LAN: a local attacker can spoof zeroconf / mDNS / DNS-SD advertisements (we will talk more about this in the next writeup ) and achieve the same code path leading to RCE.
Still, sucks for linux desktop users. Looks like any random device on your wifi/vpn can screw you over
I do not understand how the mDNS entry point works.
The original "system daemon vs. user program" dichotomy offers a much broader range of interpretations than this, though, and it was more the implication of "this can and should be an evanescent program invoked by individual users, implicitly persisting little or no state between invocations" to which I sought to object.
(That said, I take another nearby commenter's point regarding the need, and existence, of a more evanescent and safer option on systems that will never see more printing than one user does two or three times a year.)
I’ve seen network printers announce themselves over DNS-SD/mDNS and over NetBIOS, AppleTalk, etc. All of those are a layer beneath the print daemon.
On multi-user systems (accessed simultaneously by multiple interactive accounts), sure, I’ve once worked in a lab where multiplexing a printer would make sense. Make this a non-default option, please. And have a printer multiplexing daemon, not an entire shared monstrosity like CUPS.
On terminal-server style systems, the print system should be per user, because the printers are per user. I don’t want to print to a printer wherever the terminal server lives — I want to print to the printer near me.
I once ran an actual print server for a couple years. It did accounting, correctly, by wiring CUPS to a little program I wrote that actually spoke PJL correctly. CUPS, of course, can’t actually do this.
But cups-browsed is installed when you install packages "net/avahi" and "print/libppd" which I do not know what either of them are.
So I guess on Linux avahi needs cups-browsed.
ChromeOS does away with the whole idea. There are no persistent printer queues or jobs. Artifacts of the printing subsystem have lifetime tied to the user session.
Maybe it's a Gnome problem. KDE let's me see what I had previously printed if I want to see it, or reprint something.
I also know many people in pre-press who make good use of that.
Imagine if your brand new refrigerator, by default, would leak toxic refrigerant into your kitchen unless you adjusted a valve just so. This fact is not called out prominently in the manual, but if you read the fine print in the manufacturer's assembly instructions and have a working knowledge of how a refrigerator operates, you can maybe infer that this valve must be adjusted after purchase to prevent leakage. You go on their support forum to try to figure out why your brand new refrigerator is emitting toxic refrigerant, and you're essentially called an idiot and told you don't have "basic refrigerator hygiene."
People don't want to become refrigerator mechanics. They want cold food.
If you have daemons that listen to incoming connections, you only want to run them if they are sane and secure.
A firewall makes sense when you don't trust the daemons in your lair, eh, network, and you don't have the possibility to replace insecure stuff with secure stuff. But a firewall must be maintained by experts.
For a single computer it is much easier: just make sure it is secure and don't add an extra layer of complexity to it.
The reason is that even experts make mistakes, get busy, or rely on assumptions which turn out to be incorrect. For example, you thought your service which uses strong authentication and SSH was safe to expose – and then Heartbleed or RegreSSHion happened. If you restricted ingress, you slept calmly. If you had it open, you had an emergency rush to patch and look for signs of compromise.
Fortunately, in this case, cups-browsed uses port 631/udp :)
I certainly expect that a Linux laptop shouldn’t be highly vulnerable to every other device on, say, an æroport’s WiFi.
The OS you have in mind is called OpenBSD, which has had two remote holes in the default installation in about 3 decades; and if you don't need to run Linux-only applications, it actually is a pretty decent desktop.
I don't blame Linux distributions however - both Windows and macOS are way worse. We've been living through a crisis of complexity, everyone is keen to call out Electron apps but we keep on installing and using them. As long as we accept this complexity, things will keep getting worse.