You're probably not vulnerable to the CUPS CVE

https://xeiaso.net/notes/2024/cups-cve/

by alexzeitler • 2 years ago

73 77 2 years ago

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

Aachen2• 2 years ago

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.

dathinab4• 2 years ago

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.

eadmund• 2 years ago

… 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?

hypeatei• 2 years ago

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

imgabe• 2 years ago

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.

mananaysiempre• 2 years ago

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.

ho_schi3• 2 years ago

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 ^^

Moto7451• 2 years ago

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.

nebulous12• 2 years ago

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

xena5• 2 years ago

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

t-33• 2 years ago

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.

pantalaimon• 2 years ago

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.

blcknight• 2 years ago

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.

dathinab4• 2 years ago

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.

firebaze• 2 years ago

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

crtasm• 2 years ago

The one to check is cups-browsed

shakna2• 2 years ago

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

andersa3• 2 years ago

Why is your printer exposed on your public IP?

PedroBatista4• 2 years ago

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?

PlayingPossum6• 2 years ago

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?

neilalexander• 2 years ago

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?

PlayingPossum6• 2 years ago

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

PedroBatista4• 2 years ago

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

PlayingPossum6• 2 years ago

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?

PedroBatista4• 2 years ago

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.

amne• 2 years ago

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

yread• 2 years ago

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!"

TheDong3• 2 years ago

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/

IshKebab2• 2 years ago

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

dathinab4• 2 years ago

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

Joker_vD• 2 years ago

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

sureglymop2• 2 years ago

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

TheDong3• 2 years ago

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.

yjftsjthsd-h2• 2 years ago

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

mardifoufs3• 2 years ago

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.

ho_schi3• 2 years ago

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.

sureglymop2• 2 years ago

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.

Aachen2• 2 years ago

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

rcxdude5• 2 years ago

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)

pkillarjun2• 2 years ago

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.

rcxdude5• 2 years ago

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)

pkillarjun2• 2 years ago

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.

walterbell• 2 years ago

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

Ekaros• 2 years ago

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.

grubbs• 2 years ago

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

mkurz• 2 years ago

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

arprocter2• 2 years ago

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

rcxdude5• 2 years ago

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

xena5• 2 years ago

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.

rcxdude5• 2 years ago

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.

indigovole• 2 years ago

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.

You're probably not vulnerable to the CUPS CVE

Related Stories