Reading through this writeup I'd argue it's indeed quite bad, but more in the sense that the entire `cups-browsed` daemon should probably stop existing, and the Linux ecosystem should have a serious discussion about the future of CUPS in general.

These bugs look surprisingly trivial, and upstream response to what is in the end still a fairly serious security issue isn't exactly what one would expect from an installed-by-default desktop Linux package.

But no, it's definitely not worth the stop-the-world CVSS 9.9 panic.

To give the author full credit, they say

> Impact wise I wouldn’t classify it as a 9.9, but then again, what the hell do I know?

There are also buffer overflows exploitable without any user action. The foomatic vector which requires print job was just one easiest to scan and exploit.

> Wait, this is a joke, right?

Not gonna lie, I died laughing at the "Look at me, I'm the printer now" meme.

So in a way, it did have a good joke regardless of how you rank severity.

Heartbleed is a memory leak, this is a full RCE without user action - RCE obviously implies full information leakage, and more. Specifically the execution is delayed until the next time a user uses their own printer (which config has been substituted by the attacker). And the vulnerability is in cupsd-browser, not cupsd.

The author may have some attitude problem, but this is a legit Big Deal vulnerability.

From the last image in the article:

> 3. Command execution (cups-browsed, cups-filters): 9.9

> CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:L - CWE-94

Apparently there are 300k people in the world who decided they need to have their printer available to the whole internet. It does not make sense, at all, but here we are. I suspect a lot of printers are going to be vulnerable with no patches in sight, but... these should only be available via LAN. Which is still an issue, but less so than it seems.

> There's no way this is 9.9 when Heartbleed was just 7.5...

There are tons of 10s and for, what are IMO, really silly things.

The whole thing looks severely overstated. If i was in bad faith i'd say the guy is looking for fame.

I wonder, has the guy tried reproducing the exploit on RHEL/Fedora or some other SELinux-protected system? Because this looks like the kind of issue that SELinux would protect you from:

    1. cups likely does not have permissions to go and write executable binary files around
    2. cups likely does not have permissions to go and exec binaries without the appropriate labels

I still think that maybe you could steal printing document, but i haven't tried. Anyway, i see there's plenty of CUPS-related selinux work documented via manpages. Example: https://www.systutorials.com/docs/linux/man/8-cupsd_selinux/

CVSS scores are meaningless in a vacuum, and in this case it seems the redhat person who calculated them took the "fudge it until it looks bad" approach.

Below is my professional scoring evaluation while trying to keep to the ideas behind CVSS and the spec as much as I can. Although CVSS is used so rarely in my work (as it usually inappropriate) that I may have made some miscalculations.

CVE-2024-47176 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

CVE-2024-47046 4.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

CVE-2024-47175 3.3 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

CVE-2024-47177 8.2 CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H

If I apply the same exact approach to scoring Heartbleed I get:

7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

The key differences between Heartbleed and the final code execution issue in the attack chain are that Heartbleed is directly over the network (in a vacuum) whereas the code execution is entirely local (in a vacuum, ignoring the previous elements of the attack chain, assuming they were themselves fixed). Additionally with heartbleed there is no user interaction required which also raises the score. But conversely, the direct impact of heartbleed (ignoring what you can do with the information) is that it is only a confidentiality impact (although you could argue that it can lead to a crash which would be a low availability impact bringing the score up to 8.2).

I don't think this clarifies much about the scores but hopefully you can see why CVSS scores are meaningless without any context. You need to put them in the context of the environment. The other problem is that in an attack chain, the overall outcome might be bad even if all the individual issues score low. But CVSS doesn't apply to attack chains.

At the end of the day, this is a high risk issue (you say many distros have cups listen on loopback, but I think this is not true, 631 tcp is indeed loopback only, but 631 tcp is in fact commonly bound to 0.0.0.0) but only in the context of your laptop which you happen to connect to untrusted networks without a firewall.

In summary:

This problem as a whole primarily affects desktop systems and some servers.

Device running cups exposed to the internet: Critical

Device running cups connected to untrusted (but local/non internet routable) networks: High

Device running cups connected to trusted networks: Medium

Heartbleed was a different CVSS version.

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.

It sounds like in this case “exposing CUPS to the Internet” means “running a Linux desktop on the Internet” which while not something I would do doesn’t seem crazy. I would hope that a default Debian desktop installation would be secure enough to set up without a firewall.

I certainly expect that a Linux laptop shouldn’t be highly vulnerable to every other device on, say, an æroport’s WiFi.

Anyone going to a coffee shoppe and using a public wifi is exposing CUPS and can be exploited. Simple minded dismissal doesn't help anyone.

And, for some utterly and completely absurd reason, CUPS runs as a system daemon instead of a highly sandboxed user program.

Lateral movement and privilege escalation are total wins, tho.

I also cannot believe that this is the 9.9 rated CVE. For comparison, heartbleed was a 7.5. I was awaiting a Total Linux Meltdown at best and a collapse of the world economy at worst with the amount of hyping up and fearmongering that the author did on social media.

Universities are full of people with Linux desktops with public IPs and that are printing all the time: papers, their own and other's.

Uh, Linux desktops have a marketshare of some 4.5% (excluding ChromeOS which isn't affected). Even if most of us don't print (I haven't in the last year and little in the previous five), that will still be a lot of print jobs emitted by Linux hosts.

How can this be a 9.6 when heartbleed was a 7.5, how can it be just 0.4 below the xz thing

I've always disliked how on Debian, usually being rather conservative, cups-browsed gets pulled in by default if you install cups. I think "no install recommends" fixes that, but iirc some add-ons like that hplip driver pull it in again. In my home setup I just disabled the service, but it's rather annoying how more and more software spirals out of scope and makes components that could be optional a requirement. Very related is avahi-daemon. Take a desktop Debian/Ubuntu and try to uninstall it; there's a good chance it's going to remove a couple other software where you wonder why avahi would be a hard dependency.

curl developers deal with this exact thing[0] (AI generated security reports)

0: https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...

> without the requirement of user confirmation

I suppose CUPS was introduced in 1999 so it probably made sense then. But why is it still a thing today?

There are also buffer overflows which they detected with fuzzer, which can be turned into RCE without requiring user interaction. But author did not have enough expertise in this area to create actual exploit for these.

It depends on the definition of "interaction". AFAIU Alice doesn't need to print anything supplied by the attacker. It's enough if she prints anything.

Funny how the whole FSF movement started in no small part because Stallman was irritated with the low quality of printer drivers... and how that movement for some (?) reason failed, in 40 years, to noticeably improve the quality of printer-related software.

I wrote printer code for 10+ years. I appreciate how hard the technical problems are but vendors make it so much worse. I loathe printers. Printers peaked with the LaserJet III.

I feel like printers are far better now than they were 10 years ago. At least on MacOS and iOS, I have no problems finding a printer and printing. 10 years ago it was a pain, but now - smooth sailing for me. Heck, no driver installs either!

Just in: HP is adding AI into printer drivers (no joke: https://hardware.slashdot.org/story/24/09/27/0030239/hp-is-a...)

You lose job control, but I've just done a netcat to a port on my printer with my document converted to PostScript and it works fine

pdf2ps <doc> - | nc <printer> 9001

I used to have a dot-matrix printer from the 80s. I could print with "cat file.txt >/dev/lpt0". It was amazing.

Didn't do Unicode unfortunately, and monospace only, and no bold and stuff like that.

But still the best printer I've ever owned.

Do you remember those portable sh-coded HP JetAdmin printer drivers? Are you saying things today are worse than that?

I can't imagine it on a normal server expected to serve public internet requests. The way you phrased that though makes me wonder for desktop use, is there a non-cups alternative to printing on linux these days that's gone under my radar? (Please don't say there's a systemd-print...) If nothing else, probably another overdue candidate for the energetic rewrite-it-in-Rust people.

I'm more interested in whether some/all of these work on macOS, which is probably a bigger target.

> Imagine even having that thing on your system to begin with

Well it is the Common UNIX printing system...

If it was the Not-oft-used Printing System I could understand.

What’s wrong with having CUPS on your system if you actually use a printer? I’m kind of lost as the source of the “imagine”?

What would you use instead?

I'm certainly not regretting disabling avahi and cups-browsed on all of my systems long ago.

Do people have printers that move around all the time?

Also, firewalls on desktops and laptops for the win, yet again.

Windows does have a significant mitigation: whenever you connect to a new network, such as a coffee shop Wi-Fi, it defaults to considering this network Public (untrusted) and firewalls any such services from accessing it/being accessed from it. You have to explicitly set it as a "Private" network for file sharing and printer discovery and similar to work.

It's probably somewhat overhyped, but it's still a really really bad vulnerability for virtually all Linux desktops, even as presented. It's a persistent compromise of your printing system that can happen to your default Linux installation by just connecting to the same wifi/LAN as an attacker, and triggered at any point later when you print something.

And it's very likely that someone will find a way to exploit it with a buffer overflow without even having to wait for the user to print something.

Will it? The author goes to my «do not hire / hype-eater» list for sure.

yeah i thought it was going to be something in tcp stack

Possibly because the devs reduced the numbers he says: "because the devs just can't accept that their code is crap - responsible disclosure: no more"

Always kind of worrying to see vulnerability researchers justifying bad behaviour because they find a vulnerability in code. Maybe it was because his pride was hurt that he threw away any ethical behaviour?

Maybe less exciting, but still terrible for almost anyone running a Linux desktop/laptop, especially those that expect it's safer than a Windows desktop. And it's a really bad look both for the developers of CUPS, and for most Linux distros, including RHEL, that just enabled this printer discovery backdoor by default without any mitigations in place.

>Is there a recommended (best practice) way to nmap scan your network for vulnerable machines, just to be safe?

Perhaps something like this?

   nmap -sU -p 631 -P0 [network]/[mask]

Corporate organisations make use of platforms like Nessus/Tenable to provide this continuous vuln scanning for compliance reasons.

Under the hood its basically running an nmap scan and spitting out a PDF report.

Not every Linux machine is a server!

This is kind of a big deal for desktop and even more so for laptop users.

Just enabling the firewall is not enough. The Ubuntu distros explicitly wanted to allow the vector for this vulnerability: the whole purpose of having cups-browsed installed is to allow LAN printers to advertise themselves to your system.

Also this:

  > sudo ufw deny 631
  > sudo ufw reload

Unless you are exposing CUPS to other people on purpose so that you act as a print server then block inbound access using a local firewall. Your local print jobs should be able to use the loopback just fine. Your print spooler would then be talking to the IP on your printer and that should also be confined to your local network and may have optional features to further secure access.

On a very loosely related note, some enterprise printers have optional features to lock down remote access to people that are authenticated. Authentication capabilities vary by vendor. This is somewhat unrelated to CUPS but probably a good time for people to research what their printers can do as printers are a great way to steal company secrets.

[Edit] What smokel said. They beat me to it before I refreshed the page.

Unless you need printer discovery, you should probably shut down and remove cups-browsed entirely. Its whole purpose is to listen on the LAN to discover printers (or attackers) that advertise themselves to it.

Not an expert, but I guess that simply enabling the firewall should avoid most problems related to this vulnerability. In Ubuntu, this can be accomplished with:

  sudo ufw enable

Now we have something better, IPP everywhere. The protocol isn't as simple as netcating a postscript, but is simple enough, standardized and does everything expected for printing.

The last time i checked: no

They run their own software, not cups. the one i had was using their own software, if they had used cups it would have much less problems with printing.

vulnerabilities are (mostly?) in cups-browserd rather than cups.

Why are distros allowing CUPS to listen on all interfaces, then?

Sure, but that is equivalent to removing the vulnerable service entirely and the features it was offering. Listening on port 631 for connections from any machine is the entire purpose of cups-browsed, it's the only way to do automatic printer discovery. If we think the port should be closed, then Ubuntu and the other distros should also remove this service, at least from the default installations.

Yep SOP is to block all ports that I haven’t personally white listed on all my systems.

Only if the machine is directly connected to the internet and the malicious packet doesn't hit a firewall somewhere along the path.

Most laptops connected to Wi-Fi are indeed connected to an AP or a SOHO router that does NAT, so the attacker won't be able to directly reach it and this is a requirement for this to work.

The attack is about a malicious printer registering itself to your system, not about a malicious system sending print jobs to a real printer.

Then again, their printer was probably locally-networked and the documents would come in from the webserver and then be passed to the printer.

RedHat did, as per the article

botnetting is about exploiting unimportant desktops, to create very important servers.

It is irrelevant for many desktop Linux users but some distros will have installed the vulnerable software by default on desktop installations and exposed it to the network. That could make it relevant for some percentage of the small percent of people who use desktop Linux and haven't applied security updates and have network misconfiguration or other vulnerabilities exposing their machines. On a scale from 0 to Crowdstrike it is basically a 0 in terms of real impact. It is still great example of an astonishingly stupid by design vulnerability that should not exist or have survived review.

I don't know if I would say it's a nothing burger, but i don't see how it affects important servers. It might impact a number of linux desktops and, if they are linked to important servers, provide a backdoor access into important services.

Being able to run arbitrary code in a root account with no authentication would seem to be a pretty important security breach, although I don't think it's quite the level of danger it was built up to be.

1. You don't need a printer attached, you just need cups-browserd running

2. Probably your firewall, if configured, will block it. But that doesn't stop LAN requests, which can be a big deal for huge networks.

That's unrelated to these findings.