You're probably not vulnerable to the CUPS CVE | Hacker News Reader

You're probably not vulnerable to the CUPS CVE

xeiaso.net

73 pointsalexzeitler77 comments

The context is important with this one. For your web server or application server. You are probably fine.

On other hand if you run any sort of "Unix" based infra for desktops and like, there is real potential risks specially if printers are part of this.

This is more so an IT problem, not web server problem and there it can be a real deal, with possible real impacts down the line.

Just checked some GPU workstations we deployed at work recently. Ubuntu 22.04 Desktop :(

● cups-browsed.service - Make remote CUPS printers available locally Loaded: loaded (/lib/systemd/system/cups-browsed.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2024-09-27 06:40:23 EDT; 59min ago

But do you print with this machines? Like do you send them print jobs? If not, you are still fine.

Not sure of the situation on 22.04, but my 24.01.1 box just caught a bunch of CUPS updates (including cups-browsed)

Edit: 22.04.5 got them too

Oops - s/24.01.1/24.04.1

… unless you’re running Linux (or macOS, perhaps?) on a desktop or laptop and print something.

I’m pretty sure that even in 2024 printing is pretty common, isn’t it?

… isn’t it?

The only time I print something is at work and even that is rare.

I think tech people underestimate how much people want to print things. My wife is printing stuff all the time. Proofreading things on physical paper is better than on a screen. You read more carefully and catch more mistakes.

Rereading things works better when they look different, even superficially. Have you ever noticed a bug or typo immediately on a Gerrit/GitHub/etc. code review submission page that you previously overlooked a dozen times in your editor?

And scribbling on paper is still unparallelled as a thinking device for rearranging things, catching repetitive turns of phrase, and the like. A tablet with a pen works to some extent, but I cannot surround myself with tablets showing parts of the same document like I can with sheets of paper, and that’s helpful for long-form texts. No word processor with mouse-and-keyboard input can compare.

This. Bonus: We must print. Shipping labels, things which require an actual signature. And so on. And sometimes I want just hang the paper on a wall. Maybe the next print says

    “Dear macOS users. You’re vulnerable, too. Update now!”

Computers aren’t made to avoid printing. Their task is printing faster on more paper. At least this is what happened ^^

In the other thread about this it was mentioned macOS and many flavors of Linux don’t install the specific package or invoke cupsd as needed and shut it down when printing is complete. The instructions given in the article state they’re just tuning off the network discovery package for CUPS.

this article appears to be geared towards linux on a server rather than a desktop

Author here. Any randomly selected Linux machine is more likely to be a server than it is a desktop.

Any randomly selected Linux machine is most likely to be a mobile phone, statistically speaking

Are you sure there are more Android phones than Linux servers?

I don't think there's a way to check for sure but I'd say that's pretty likely. There are billions of android devices, and Linux servers, while popular, are probably less common just because servers are less common than consumer devices in general. But maybe I'm wrong!

I'm pretty Android doesn't use CUPS, and most people that use Android don't consider themselves Linux users. I think it's okay.

True. Linux machines don't read articles though, people do. Whether any randomly selected linux-using reader will have cups installed on a device they control is a very different question.

CUPS isn't required for printing on *nix, and even if you use it, cups-browsed isn't required. If you need to "discover" the printers on your network, something is probably wrong, as in my experience public printers are always labeled with the relevant information and home printers can print or show that information on their menus.

What alternatives are there to CUPS when it comes to printing?

And yea sure you can manually configure your printer, but it's a pain in the ass compared to zeroconf auto-discovery.

I just use lpr or netcat if I haven't written a printcap on a system.

How would I do that from a browser?

Your browser probably reads printcap to get the printers already. So, the same way you already print from the browser. You can also print to pdf and then send the pdf to the printer from the commandline.

> If you need to "discover" the printers on your network, something is probably wrong, as in my experience public printers are always labeled with the relevant information and home printers can print or show that information on their menus.

This is a terrible take. The average user is not going to go find out the IP of the printer and go on their computer and configure it. Discovery is the primary way people print now.

And... CUPS is how 99% of people print on Mac or Linux.

not really

I mean it depends a bit on your living situation.

I mean at jobs (e.g. self employed) you have to sometimes print things I guess often enough for it to be a viable attack.

And as a student if you might also sometimes prefer paper, but most universities have printer pools you mostly use over USB and that is just way cheaper then your own printer.

Sure if you play games like D&D you might print character sheets (or templates for them) but how often?

I think the last time I had to print anything was when I sold my car like 7 years ago (doesn't make sense to own one where I live).

And sure not everyone will have that experience but the combination of run Linux + has network discovery enabled and "publicly" accessible (i.e. no strict firewall) + uses a printer over the network before it's fixed + gets attacked with it seems not "that" high, actually as long as the fix is delivered quite fast and it wasn't abused for years it seem quite unlikely.

Popos (out-of-the-box): cupsd running, but on 127.0.0.1.

The one to check is cups-browsed

First I thought, "S%%t, I am hacked," because I know in Fedora CUPSD is installed by default and runs at boot.

> /etc/cups/cupsd.conf

> Listen localhost:631

After some checking, I found out by default CUPSD only runs at localhost. So, yeah, you don't have to worry about this in Fedora either.

That's the TCP port cupsd listens on. You want to look at the UDP port cups-browsed listens on (which is where the problem is, and it isn't configurable: if cups-browsed is running, you're probably vulnerable).

In general I would say don't look at config files to verify this kind of thing. Use something like 'ss -lp' to get a list of what processes on your machine are actually listening on (anything that isn't 127.0.0.* or [::1] is generally going to mean network-accessible)

> sudo lsof -n -i -P | grep -i "cups"

>cupsd 2843 root 7u IPv6 12941 0t0 TCP [::1]:631 (LISTEN)

>cupsd 2843 root 8u IPv4 12942 0t0 TCP 127.0.0.1:631 (LISTEN)

There is no open UDP port for CUPSD, so relax.

because it's a separate daemon that listens on UDP. But it looks like at least it's not enabled in your config.

It's worth noting that while the PoC requires the user to print to the maliciously installed printer, there were also multiple bugs in the parsing code of cups-browsed which could cause crashes and are quite likely exploitable (and likely will be, shortly).

Those buffer overflows (should they exist) were not in the security bulletin. I personally give more weight to things that have been reported to exist than things that likely or probably exist.

Thye've been reported to exist in the blog post by the guy who found this issue. He didn't care to make another PoC for it, but you can be sure others are looking at it now.

Notably Debian pulls it in by default so if you've set up cups on a server, cups-browsed is likely up and running.

Not targeting the author as this appears not to be the case and he provided helpful advice, but it bugs me to no end how a not insignificant amount of people deals with security vulnerability and concerns. How casual, dismissive, aloof and many times straight up hostile and the most infantile ways they act when someone raises ( very valid ) concerns about security.

I've seen this over and over again with Linux people, granted this view might be skewed because of the public reach of the project, but still.. they seem to view any communication regarding CVEs or security concerns or design recommendations as adversarial and tend go into the "I know more about Linux than you" and "Everything is fine until you convince me it's not, which will be never" mode.

Not wanting to turn this into a dunking contest but, it's the general feeling I have about this.

It doesn't help that people rated a CVE 9.something for a PHP vuln in a barely used method of an extension that can be exploited if you use .. I forgot .. ah yes .. IIS.

Peter says wolf too many times?

Maybe a CVE should have a complex score (severity / spread): 9.9 / 4.

severity 9.9 : easy to exploit if you run this .. you're cooked

spread 4 : you most likely are not running this or it's by default in a way that you're not cooked

Indeed, CVSSs don't take into account how widespread the software is. You know it. Why are you surprised it got 9.9? It seems the cve shows how to completely pwn cups so it has a high one. I don't run pg but I'm not going to be moaning about the recent vulnerability in pgadmin being 9.9 "ugh why so high? I don't use it!"

> he provided helpful advice

They use the 'they/them' pronouns.

Do you run a large open source project or website that gets security contacts? The vast majority of security reports are poorly written and bogus, with the person either trying to get money or pad their resume with CVE. I think that contributes to developer's wariness of these things, and the "please prove that this is a real security issue" attitude you often see.

May I reference:

Beg bounties - https://news.sophos.com/en-us/2021/02/08/have-a-domain-name-...

The bogus CVE problem - https://lwn.net/Articles/944209/

Yeah it's because they identify with Linux and so if anyone points out a flaw in Linux it feels like pointing out a flaw in them. You often get the "you're holding it wrong" defence - in this case "obviously you shouldn't expose CUPS to the network!" despite the fact that that's clearly useful and should be how things work.

There's an example in this thread: https://news.ycombinator.com/item?id=41668979

The context you are missing is that the person who had discovered this vulnerability has mad it up to be basically on the line of a easily doable RCE in every server you have (and every desktop Linux). Something which if you work in a position related to system administration can easily mean a bunch of unplanned overtime. Which is very very different to the IRL situation of "oh we are most most likely not affected but to be sure just disable printer discovery temporary".

The post isn't meant to be dismissive of there being a vulnerability, it's dismissive of it being "so bad you can pawn all Linux systems ever", especially in context of servers. And if I had to guess it partially exist so that if people (as in people doing sysadmin stuff) consult here she can point them to the blog post instead of repeating herself over and over.

Through in general I agree that there are parts of the Linux community which do not handle security concerns well at all.

But also there is a trend of people which do not understand what they are talking about and refuse to learn or people which just want a ton of attention blowing up security issues out of proportion again and again. And that is bad kinda like the story of the child who yelling wolf except it's like 50 adults yelling wolf. It also can lead to all kind of other personal annoyances like you having to unnecessarily doing overtime and wasting time with having people to tell again and again "yes we are fine, this doesn't affect us, actually this doesn't affect most server setups. Yes they said otherwise, yes they knowingly misrepresented facts when they announced that there will be a vulnerability beforehand, no they never had a good reputation but we have to take them serious anyway, etc. etc.". So I have quite a bit of understanding for some people in the field being sometimes quite annoyed (not for all of them tho).

(Also to I think you might be reading a bit too much into here blog post and my comments above where meant to be "in general" not specific to the blog post.)

I sometimes do a port scan when I am in a foreign network.

What I find interesting is that people generally seem to not know that 0.0.0.0 means "all interfaces" and have a lot of stuff running and accessible from the network. I've seen developers running their live reload server, different software (i.e. syncthing), webservers, even databases (someone running postgres on their laptop)! So, I've long thought that this is the part that actually confuses people and it even happens to otherwise technologically competent people.

I also have often run into software where configuring the default listen address and port seemed to be way harder than it should, sometimes even requiring changes in the source code. So, I really think we need to start shipping some kind of client side firewall with a good UX by default (something like little snitch?).

I think one of the culprits of this bad default is docker containers.

Since docker by default runs your code in a separate network namespace, in that context '127.0.0.1' really means "accessible inside the container, effectively nowhere", and '0.0.0.0' means "accessible only on the local machine" (except that's not actually true, check out this open issue lol https://github.com/moby/moby/issues/22054 )

I think that's one reason for some software's default of 0.0.0.0 - people are cargo-culting from stuff that runs in docker and/or people want their stuff to run in docker and work by default.

This is only going to get worse as snap and flatpack become more common, since they have the same property.

> and '0.0.0.0' means "accessible only on the local machine"

I don't think that right? It just means "is available to be mapped out of the container", but you still have to use -p or such for it to do anything

You don't have to use -p with docker's default settings.

    $ docker run --rm --name listen busybox sh -c 'echo hi | nc -l -p 8000' 

    # in another terminal
    $ docker inspect listen -f '{{ .NetworkSettings.IPAddress }}'
    172.17.0.3
    $ nc 172.17.0.3 8000 < /dev/null
    hi

Works just fine for accessing it on your local machine. The -p flag is meant to "publish" a port so it's available remotely, from outside of your machine (i.e. to serve nginx to the public internet on a webserver with '-p 80:80' or whatever).

I think that the decision to use 0.0.0.0 in this case predates docker by a lot? Which to me indicates that docker used it because it was already a widespread (bad) default.

> So, I really think we need to start shipping some kind of client side firewall with a good UX by default (something like little snitch?).

This is not a solution but makes it worse. Adding more vulnerable code widens the attack surface. The history of so called security software (aka snakeoil) has shown that it doesn’t protects but causes more harm.

A Linux system shall show with “# ss -lpn” [1] only ports and process which are known and reachable. It easy to use and that the functions people want - knowing who is doing what. And that’s the path Linux and BSD have taken successfully in the past.

Firewalls are a valid way for administrating networks itself. And while firewalls come lean and integrated on Linux, they should be used carefully. I think system-monitor tools should show open sockets and ports, like they show processes itself, in a list.

[1] https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems... -> The author use the old netstat. And recommends to just turn the service off. That ensures that CUPS doesn’t make other mistakes. A thing a firewall will not do.

PS: At least the Wiki of Archlinux recommends for quite some time not to install `cups-browsed` because it isn't usually need for printer discovery (IPP-Everywhere/AirPrint). At least since December 2022.

Of course you can use netstat and ss or iptstate and of course I use these. I don't even have cups installed. I'm not talking about a user who has full control and awareness over their system already.

What I'm proposing is a backwards compatible "sane default" for people who may not understand. They should get a pop up which has them confirm that the service they are starting will be open to the network they are currently in. macOS has pop ups like this for many things and it seems to mostly work, it shouldn't be that hard.

I don't fully understand your point about firewalls being a valid way for administrating networks themselves (only). Linux ships with netfilter by default, nothing stands in the way of better defaults.

Thanks for your response.

Desktop Linux ships with sane defaults, other then Windows. Most of us will not have cups-browsed installed.

The notifications/permissions you mention are good proposal! Actually we want permissions and it happens already with Flatpak. And the operating-system should even ask for it outside of Flatpak. It doesn’t need a Firewall and therefore creating wrong[1] (i.e. DROP) responses.

What system-monitors still lack is showing network connections like they show processes. The should all come with a tab which displays something like ss -tulpen.

    * Less code, less issues
    * Overview about what is actually used.
    * Permissions prevent undesired changes to this state.

We don’t want to block a dangerous application with a firewall. We want to turn it off. Update it or remove it? I want to be a step ahead and keep the port closed.

So I desire correct network responses, minimum code acting to reduce error probability. That is already the case. But I want more, permissions and overview of current state for all kinds of users. Not the case, ss is and netstat are good but for professional users and even for professional not the best.

The difference in the firewalls in networks is, that admins care about a network, cannot control all systems, lack historical overview and (sadly) know that various network services aren’t save. Then, use Firewall. Maybe it is just tape around a problem but it is intended for that problem.

PS: A nice article on Ubuntuusers (German) explains why Ubuntu doesn’t use a Firewall despite Netfilter is integrated: https://wiki.ubuntuusers.de/Personal_Firewalls/

The background is that Windows users keep asking again and again why Ubuntu ships without a Firewall. Linux ships with one but it is not supposed to be used as „Desktop Firewall“.

The Chaos Computer Club finally made fun of commercially available Desktop Firewalls with a lot of stupid extra code[2] (Don’t compare them to Netfilter!) twenty years ago: https://ulm.ccc.de/ccc/chaosseminar/2004_12_personal_firewal...

Fake message from DNS1. Fake message from DNS2. The Desktop Firewall removes Windows from network because it blocks now the real DNS. It is old but even today the same things happen again and again.

[1] Bad. This is not what we want in a proper network. [2] It is not a mere firewall. It is not integrated into the system like Netfilter. It just a lot of extra code and tries to be smart. Which fails.

I think people do know, but don't care much on internal networks and also don't check in netstat what's actually exposed after installing either the base OS or additional system packages

Host firewalls like ferm or ufw also make it easy to ignore these port bindings because it'll be blocked anyway. Whether that's the right mindset ("just bolt something else on"), idk, but that's the current practice

A sensible (and reasonably common, but sadly not universal) default is to listen on localhost only, and require configuration to listen on all interfaces (or a specific non-local one)

You can't just dismiss a vuln as, "for the love of god, don't expose XXX to the internet."

It's not great to have an unauthenticated RCE on a machine that is _not_ accessible from the internet, either. Inside-the-network RCE is useful for lateral movement and privilege escalation. RCE that you can find by looking for an open UDP port - instead of a vuln scan on 80/443 - is even better.

Initial entry is an important vuln abuse case, but not the _only_ abuse case.

> Also for the love of God, don't expose your printing service to the public internet.

300k and counting.

Weirdly enough, my printer is running cups-browsed, and available via my Public IP. I'm assuming some hack to transition one kind of machine to another - though that means it is running a full kernel, which is kinda astonishing.

But the POC works to control it, so...

Why is your printer exposed on your public IP?

Do you really think out of the millions upon millions of installations with wildly diverse contexts and situations all the people including the unsuspecting users CHOOSE to "expose the printer to a public IP"?

Seriously, how are we still at this level of discussion?

I am simply confused how it happened, because every consumer router I have ever used in the past decade defaults to not exposing devices.

IPv6?! The big thing about this was that you'd have end-to-end connections without NAT etc.

Which still doesn't mean exposing everything publicly, but that is a different discussion.

In general I agree, most people affected probably didn't choose to expose the port it just "somehow accidentally happened".

IPv6 doesn't mean no firewall.

The wonderful setup of Telstra's Technicolor, at least the one I'm mandated to use by some great NBN contracting, automatically exposes:

+ All ports below 505.

+ Any port requested by NAT.

+ Any DynDNS request.

The printer made a NAT request, and now it's public.

Wow, that is terrible!

> Unless your servers can print for some reason

> This may vary by distro and cloud image, but in general your servers should not be vulnerable to this. Your desktops may be.

... if you're not running CUPS then you're not affected. Noted.

if you are not running cups browsd some kind of printer auto discovery service you are not affected,

and multiple distros e.g. only start it temporary if you are about to print. So even if you run cups in some cases you also have to actively print for it to be exploitable.

Hopefully there's nothing lurking in libcups2, https://packages.debian.org/sid/libcups2

> dpkg showed it wasn't installed, but it was listening due to their horrible sidecar "snap" package system.

Oh no, there are two distribution-mandated package managers on my system but I refuse to acknowledge the existence of the second one because it offends my sensibilities. Well, add another step to your Ansible template, I guess: "apt autoremove --purge snapd && apt-mark hold snapd".

Correct me if I'm wrong, but to be affected, don't you need to have UDP port 631 exposed to the outside world? Apologies for being a bit blunt, but if you're exposing services like printing to the internet that shouldn't be exposed, well, then... you kind of deserve to get owned, right?

> you kind of deserve to get owned, right?

The people who have no idea what services are listening on their machine due to some default that someone else decided upon absolutely deserve to get owned, yes, because that's a totally reasonable mentality to have.

Sarcasm in case it wasn't obvious. At what point did it just become normal to be so user-hostile?

To be fair, most regular users are not impacted by this vulnerability. That is exactly what is written in the article.

OK, I'll correct you :)

This is the quintessential wrong way of thinking about computers and security. It's the equivalent of the "OK, but.. [insert BS argument trying to deflect]". There is no "but", "Your" system has a bug/vulnerability/non-compliance - FIX it and help the users/customers instead of waterboarding us with pseudo-moralistic quips about "deserving" and whatnot.

The Universe is quite a big place with realities, situations and contexts you wouldn't even fathom. Be humble.

( Hope I wasn't too blunt :) )

I mean, if you install your server and open it to the internet without securing it with a FW, what would you expect to happen?

Seriously, and I mean this in the most non-aggressive way: Grow up.

Seriously, anyone who disagrees with that ends up with even bigger problems, like getting hit by ransomware. You, not some developer or Linus Torvalds or anyone else, are responsible for your client and your data. If you put your server on the internet without securing it properly, you deserve to get owned. Your negligence ends up hurting other people.

Is that so hard to understand? You have to take security seriously. My point is that a firewall is the bare minimum you should be thinking about when setting up your server.

The issue is when people don't realize that CUPS is installed either because it happened by default or was accidentally brought in through some other transitive dependency. Ubuntu is especially vulnerable to dependency smuggling like that because recommended packages are installed by default.

Don't blame or anger at people for not knowing their stacks entirely. There's so much to keep track of that it's totally understandable that something like this can fall through the cracks.

That's the point - you don't need to know your stack. You don't need to worry if CUPS is installed, enabled, or listening on your interface. You don't need any of that, as long as you do the bare minimum and configure your firewall.

That's the whole point!!!

Depends what you mean by "expect":

1. To predict or believe that something will happen

I expect it to get hacked because it's written in C.

2. To consider obligatory or required.

I expect servers to be secure!

Exactly, and I think you'd expect the people managing those servers to be experts and do their job. That's the whole point of what I wrote.

Who said anything about servers? This mostly affects consumer devices. If this was a windows installation, I'm not sure the same "skill issue" argument would be popping up. A normal person just installs their OS and uses it. They don't know the intricacies of CUPS, the implications of using 0.0.0.0 or how to set up a firewall in a way that would prevent this from happening. Hell, even tons of people on HN make the mistake of just checking their TCP ports when discussing this issue (when it's UDP), or don't check for the right cups package. So imagine everyone else?

Reply on news.ycombinator.com