> 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).*
(emphasis mine)
There's no way this is 9.9 when Heartbleed was just 7.5...
EDIT: Wanted to add why I think he has overblown this way too much. His original tweet stated "* Unauthenticated RCE vs all GNU/Linux systems (plus others)" but as we can see this isn't nearly the case as on a lot of distros CUPS only listens on loopback or isn't installed at all.
Another point:
> Full disclosure, I’ve been scanning the entire public internet IPv4 ranges several times a day for weeks, sending the UDP packet and logging whatever connected back. And I’ve got back connections from hundreds of thousands of devices, with peaks of 200-300K concurrent devices
If I'm understanding this correctly, he only found 300 thousand open CUPS instances in the whole public IPv4. Remember - the CUPS server needs to receive a print job in order for the RCE to happen, which I doubt most of these instances will get.
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.
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.
Thanks, I missed that. But that still leaves us with only 300 thousand exploitable instances in the whole public IPv4 address space. This is nowhere near a universal GNU/Linux RCE. Of course it's still a big deal to those affected servers, but it's nowhere near even RegreSSHion.
No, the author said that the peak concurrent connections was 300k. That tells us there are at least that many vulnerable hosts publicly exploitable, but there could be many more that are transiently exploitable.
Also, this attack is easily triggered from any LAN, such as an airport or university or corporate or coffee shop network. And it is persistent: the attacker persistently registers a "printer" on your system (potentially overwriting a real printer that you actually have), and later when you print, even disconnected from the internet, you can trigger the RCE.
If it's an open network, and there are still quite a few of those, it's not hard to broadcast packets over the air and fool the receiver into thinking they're coming from the connected AP.
Most run by commercial enterprises do, because they have teams running them that care about security.
Your average non-large-brand coffee shop or ho(s)tel? They stick some cheap ass router in and disable the wifi password to get a public wifi for their guests.
The socket activation thing it has with systemd as well, but I don't know if there are facilities for automatically shutting it down like that as well.
That's a nice touch, and it'd be cool if Linux distros added that.
Generally, CUPS on a Mac is bound to localhost. It is highly atypical for a Mac to make it so any computer on the internet or even local network can make requests to its cups server.
The problem isn't CUPS itself, it's the automatic printer discovery mechanism. That's cups-browsed on Linux, not sure how it's achieved on a Mac.
And the printer discovery service can't be firewalled: by definition, it has to listen for outside connections to be in any way useful. This is where things like Windows' trusted VS untrusted networks make sense: it's perfectly nice to allow printers to register to your system on your home network, it's a horrible idea when you connect to an airport wifi.
> The standards-based, open source printing system developed by Apple for iOS®, iPadOS®¹
ships on iOS® and iPadOS®.
But maybe it doesn't.
¯\_(ツ)_/¯
In seriousness, exposing only a very limited interface to a flexible, capable system seems to me very on-brand for Apple.
Maybe they don't iOS and iPadOS to be of the kind of platform where one thinks about drivers, even if exposing CUPS features to users would let users accomplish more without much trouble.
Or maybe they see printer drivers as essentially a legacy feature in the face of a 'driverless' future.
Not my cup of tea, but both seem like things leaders at Apple would do/think.
Yes, and CUPS was used on macOS, from which iOS was forked before Apple releases the first iPhone. And from that same year (2007) until 2019, Apple employed the creator and chief maintainer of CUPS, which is presumably how they got their hands on the cups dot org domain. Then (as is typical of Apple's treatment of open-source), Apple stonewalled outside contributions and public releases became increasingly sparse and insignificant. So the creator and longtime ch8ef maintainer of CUPS, now outside Apple, created a new fork under the OpenPrinting banner. Thus CUPS became 'Apple CUPS' and the 'CUPS' everyone else cared about was now OpenPrinting CUPS.
My point was that Apple's language on the website indicates that they probably use CUPS on iOS and iPadOS, not that that language describes CUPS' origins or is informative about the nearly three decade history of of the software or the current landscape of its forks. (Although in fairness to Apple here— a company of which I am not a fan— 'developed by' doesn't mean the same thing as 'authored by' or 'created by'.)
> I can tell you that there’re other, more easily exploitable code paths going on, not just in the discovery mechanism - also reported and ignored. To this day they have not been acknowledged or patched.
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.
It's RCE (as the lp user, if I'm not mistaken) with user action, and only if the firewall isn't blocking required ports. Most systems, even most systems with CUPS installed, never print anything. The number of systems with no firewall (where "firewall" here could just be NAT) that actually print something is even smaller.
In isolation (which is what CVSS is all about) this is not a network exploitable vulnerability, even if you can craft an attack chain which exploits it over the network.
So:
AV:N -> AV:L - reason above
AC:L - correct
PR:N -> PR:L - to exploit this you need to get cups to process a PPD file. Ignoring how it got there, writing a PPD file requires low privileges on the local machine (unless I'm wrong and you can't add a printer to cups as a local user by default, in which case this becomes PR:H with an overall score of 7.7). These might be fulfilled by another component of the attack chain, but again, you need to strictly think in terms of the vulnerability in a vacuum.
UI:N -> UI:R - that a user must perform a task after you begin exploitation in order for the exploit to complete is a classical example of required user interaction
S:C - correct, attacking cups and getting root on the whole machine is considered a scope change
C:L -> C:H - Running arbitrary code as root on a machine is a total breach of all confidentiality of the local machine, so not sure why this was marked as low.
I:H - correct
A:L -> A:H - Running arbitrary code as root on a machine lets you do anything to completely disable it permanently. Availability impact is high.
In summary a score of 8.2 (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H) for CVE-2024-47177 in a vacuum.
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.
It's not that. Apparently, several major Linux distros, and the cups-browsed developers, have decided for people that any device on the internet should be able to connect to their system as a printer.
Firewall lets it through: cups-browsed explicitly listens for printers advertising themselves. If it's firewalled off, how can it receive the printer advertisements?
I don't know what default firewall rules are configured, but on distros that run it I'd assume it's allowed through, otherwise no reason to run it.
That should protect you from Internet-based attackers, but it doesn't protect you from attackers on the same LAN. For example, if you're in a coffee shop and using their free public wifi, an attacker in that same network can trigger this.
Maybe some may fall into the IOT/Embedded category. Wouldn't be very surprise if i.e. a cheap wifi camera have cups installed just because and jumps out in this scan.
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.
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
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
If that's the case, this would really be a testament to SELinux and the final blow to AppArmor or whatever Canonical is shipping nowadays (clearly useless).
Hard disagree. FS permissions take like 5 minutes to explain and then you maybe need another 30 minutes in total to try around and get a hang of it. I've given up on selinux every time I've tried to make sense of it. Open 3 different tutorials, have 3 totally different approaches to it.
I guess if you only install core packages on redhat and never touch a single config file it might work OK even for the average Joe.
I found that for me, SELinux is best mastered by reading the documentation. Most tutorials I read when trying to make custom policies and monitor how policies were working, were hot garbage written by people who were just reading other people’s tutorials. SELinux solves problems orthogonal to FS permissions, and use cases that FS permissions alone don’t address.
It was a bit tough at first but writing your first SELinux profile is a fantastic way to make it approachable. YMMV, of course.
> The first thing many do in the real world, after installing RHEL or the free derivatives is ... turn off SELinux.
The people with port 631 publicly reachable didn't configure their firewall either (neither at OS level nor at infrastructure level) so what now, firewalls are useless?
Are you suggesting that people should not report remote command execution vulnerabilities when such vulnerabilities are successfully stopped by SELinux?
Also, why do you think that seeking recognition for your efforts a bad thing?
> Are you suggesting that people should not report remote command execution vulnerabilities when such vulnerabilities are successfully stopped by SELinux?
No, I'm suggesting that only testing on system shipping weak protection systems and poor defaults is misleading.
> Also, why do you think that seeking recognition for your efforts a bad thing?
It isn't by default, but it can become a bad thing when you overstate the importance of your finding: see my previous line in this comment and add the fact that this guy picked a cve score of 9.9 where heartbleed had "only" a 7.5 score -- but heartbleed affected pretty much everybody in the industry.
> But here’s a screenshot from the VINCE report of the initial CVSS scores, including the 9.9, being estimated by a RedHat engineer (and also reviewed by another one)
> As I said, I’m not an expert, and I think that the initial 9.9 was mostly due to the fact that the RCE is trivial to exploit and the package presence so widespread. Impact wise I wouldn’t classify it as a 9.9, but then again, what the hell do I know?
> No, I'm suggesting that only testing on system shipping weak protection systems and poor defaults is misleading.
But then he would not have found and reported the vulnerability, yet it would still exist and affect people.
Once the vulnerability was discovered it doesn’t matter if one operating system or the other has protections in place that will stop it. What matters is that the code is vulnerable and that there are people who are not protected. Proving that it is not exploitable on systems configured a certain way does not invalidate the original finding.
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.
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 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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
And this is why Microsoft force pushes updates. I think when Linux desktops become really popular there is quite a worry if the users simply do not update them regularly enough. Or if they are not secured in most ways by default.
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).
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.
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.
> I would hope that a default [OS] desktop installation would be secure enough to set up without a firewall.
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.
The prevalence of attitudes like this in the Linux community is why the year of the Linux desktop will never come.
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.
Because you don't need a firewall on a sensibly configured desktop computer.
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.
That attitude was popular in the 90s but any definition of “sensibly configured” in this century involves a firewall.
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 encryption 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.
On Ubuntu, both.
A system daemon with interesting interactions with avahi-daemon and colord, and a somewhat sandboxed user program, just so Chrome is not overly inconvenienced by its snap sandboxing.
But wait, there is more: The login & lock screen also runs the whole glory of GNOME.. to query printer settings. So you can have those sweet, sweet "new printer" notifications overlaid while inputting your password. Or whatever else "your" printer needs to add there.
It's a spooler for a printing system that supports concurrent job submission, potentially among multiple users. It's going to have to achieve serialization some kind of way.
As long as that user can talk to the printers' device nodes (and/or the network), it needn't so far as I know.
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.)
They don't. cups-browsed is a legacy component that isn't needed on ordinary systems, which outsource printer discovery to an mDNS service such as avahi.
I believe these vulnerabilities only allow RCE as the 'lp' user (which is able to access parallel ports and USB devices that identify themselves as printers). In addition the process will be confined by MAC policies (e.g., on Fedora/Red Hat I think they're confined by cupsd_t).
I have never, in the entire history of my usage of desktop systems, wanted my system to spool out a print job on behalf of a non-current user. Nor have I wanted my system to continue servicing my print queue after I log out. To the contrary: it’s incredibly annoying when the queue glitches out and then my print jobs show up in the printer tray after I’ve left.
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.
It's because of the frankly idiotic idea of persistent print queues. If you want to have this artifact that survives a user session, then the print subsystem needs super-user abilities.
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.
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.
Yeah tbh it's not as bad as he claimed. I doubt this is actually rated 9.9:
>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
Keep in mind that you still need send a print job to the fake printer to trigger the exploit. If you send the job to your real printer, nothing happens.
Depending on your interpretation of the Scope metric in CVSSv3, this is either an 8.8 or a 9.6 CVSS to be more accurate.
In summary, there's a service (CUPS) that is exposed to the LAN (0.0.0.0) on at least some desktop flavors of Linux and runs as root that is vulnerable to unauth RCE. CUPS is not a default service on most of the server-oriented linux machines like Ubuntu Server or CentOS, but does appear to start by default on most desktop flavors of linux. To trigger the RCE the user on the vulnerable linux machine must print a document after being exploited.
Evilsocket claims to have had 100's of thousands of callbacks showing that despite the fact most of us have probably never printed anything from Linux, the impact is enough to create a large botnet regardless.
Having a public ip address doesn't always mean there's no firewall in between a pc and the public internet, ideally with sensible default rules. It's not 1996.
And sorry if I'm being a bit harsh on this, but this point comes up every time when ipv6 is mentioned, by people that clearly don't understand the above point.
The point is that, if printing works for those people, then we know they have this port open, at least on the university network. So even if it's not exploitable over the internet, it's definitely exploitable from the whole university network, which is almost as good as from the internet.
Just to add a datapoint to the previous comment, my large public US university hands out public IPs to every device on WiFi. If there is a firewall, it doesn't block 8080 or 22.
Yes. It's rather sad that so many people equate NAT with a firewall. Two totally different things. A firewall is good, NAT is annoying. We need to push IPv6 harder.
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.
But real answer is well if you have arbitrary remote code execution you can also read memory, where as heartbleed only read memory... And the reality is same, you were safe from heartbleed if you did not use openssl, you are safe from this if you do not use cups. CVSS score does not take into account if the software is used or not.
I guess a part of the issue is that it was reported as a "9.9 severity vulnerability in Linux" in a bunch of places, which makes it sound incredibly severe, whereas a "9.9 severity vulnerability in CUPS" doesn't
I panicked a little when I heard the news as I run a cupsd open on the Internet. But as it turns out, the issue is misrepresented in headlines, just like here. This is not an issue in the core cupsd, but in a separate package/component, called cups-browsed. My distribution of choice for servers, Gentoo Linux, ships cups-browsed in a separate package which I had not installed, meaning I, as well as most other cups users that did not install this additional package, am not affected by this bug.
Saying that all systems running cups can be hacked is a misrepresentation of the scale of the issue.
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.
1 - cups-browsed is able to install printers automatically (without the requirement of user confirmation) by listening to UDP packets on port 631.
2 - Attacker uses this "feature" to install a fake printer with a custom driver (which is also installed without user confirmation and can be downloaded from an arbitrary host) which specifies the "command to run" when a print job is sent.
3 - User prints something in the fake printer and the "command to run" is executed.
I would rather expect this kind of change came later, when there has been a huge push to make the "linux desktop" more user-friendly.
1999 sounds like the time when people were a bit more expected to mess with config file and somehow always had a root terminal around. If anything, keep in mind that in 1999 it was still a rite of passage to have to learn how to write the X11 configuration file (what used to be xorg.conf)
I’d shift that a little earlier (XF86 autoprobing worked for a lot of hardware by the turn of the century) but especially also recognize the competitive environment. Mac, Windows, OS/2, etc. users had been using local network discovery since the 80s, and the people trying to popularize Linux on the desktop were all too aware of the “by and for computer nerds” reputation they were trying to shake, and a lot of people still thought about corporate networks as isolated enclaves where nothing too dangerous happened. The threat model for a lot of people, even server admins who should have known better, was more along the lines of “someone will print a picture of their butt on your desktop printer” rather than “your workstation is now being used to attack the accounting system”.
> That a lot is expected and taken for granted from the security researchers by triagers that behave like you have to “prove to be worth listening to” while in reality they barely care to process and understand what you are saying
The unfortunate reality is that for every well-researched report like this one, you get 57 low-effort spam reports that hope to extract a bug bounty reward, or get a CVE discovery listed on their resume. Especially with the rise of LLMs that kind of spam can easily trick you. It's a sad situation, but I don't entirely blame developers for being skeptic.
While in this case distros include cups-browsed maybe as a feature, I always feel it's a bad thing Ubuntu/Debian (and maybe all deb-based distros?) automatically bring up almost all services upon installation. This means you can install a package and accidentially open another network service that's installed as a dependency.
You probably already know exim4 (to be fair it listens to only localhost by default, so maybe not a big deal). I just tried to install cups-browsed on one of my Debian machine, and it brought up two services that listens to 0.0.0.0 (cups-browsed and avahi).
This is not the case for Arch/Gentoo and CentOS-like distros.
The original CVSS score on Twitter indicated that user interaction was not required. However reading the RCE chain on the page says:
Wait for a print job to be sent to our fake printer for the PPD directives, and therefore the command, to be executed.
If Alice never hits print it seems like a print job will never be triggered. Am I missing something? I'm not questioning evilsocket, I'm trying to check my understanding.
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.
I agree that Alice just needs to print anything but that seems like user interaction required. Its also not clear if Alice has multiple printers defined does it matter which printer she selects?
The attacker can replace any and all printers, so not entirely. I'm not sure how the UI part of CVSS is specifically defined, but I think it's at least somewhat fair to call something the user is expected to do unrelated to the attack in any way "no interaction". Otherwise, it's like saying "the user has to power on their device and turn on their Wi-Fi for the attack to work, so it requires user interaction".
The question I had is whether the attacker can enumerate known printers, too. Replacement is a lot more damaging if they don’t have to discover the name of your default printer first.
The interaction question is complicated because there are three modes: the most damaging is when the attacker can trigger the exploit directly, since that’s where we start seeing worms and other untargeted attacks. The next level is where the attacker can exploit something the user normally does - hence the question about default printer replacement since that is something the user has done many times before and thinks of as safe. The lowest level of risk would be if they need to get you to click on a different printer: still bad but nowhere near as easy to exploit on a large scale.
Every time I need to print something on MacOS I am reminded of how much I hate printers and any printer related software. I've been messing around with computers for 40 years now and goddamnit, every decade printers become more of a pain in the neck.
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.
Agreed, I ran several busy printers for a large department. The ljet IIIs were work houses and ran nearly forever if you used the recommended part replacement schedule.
We had a ljet III that outlasted ljet 4, ljet 5, and ljet 4000. Ljet 3 was the last with the HP print engine, afterwards they used Canon print engines.
The network interface was brittle, even a nmap would hang the printer. So we firewalled it off and used CUPS to handle postscript -> PCL. Sending only PCL to the printer (postscript memory and CPU is unbounded) made them faster and MUCH more reliable.
IIRC the Laserjet 4 had a much better warm-up time (and lower power consumption) by switching to a thin ceramic heating element rather than heating half the printer. But yeah anything after that is downhill.
do you mind lightly summarizing what technical problems make it more difficult? I'm assuming there are all sorts of things web-devs never even think about from that world.
Poor status, often a 1 line LCD says "processing..." and hangs infinitely.
Different handling of duplex, monitoring ink levels, file formats (PS? EPS? PNG? PCL? Which versions? Etc).
Issues with ink that expire by date, reduced functionality with 3rd party inks, not being able to print black even when only yellow is out of ink.
Different postscript versions and the nature of a language where CPU and memory use is unbounded means you get a nightmare of which files can print to which printers.
Most of our printer nightmares, at least the software issues, ended when we handled postscript -> PCL (a raster based format) on the server side.
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!
Yeah something like 10-15 years ago I thought for just the simple action of printing a file, it was way easier in Ubuntu than Windows, simply because they included a lot of drivers in the distro by default, while in Windows land I still had to visit the printer manufacturer's website for drivers -- or use the included CD! I try to avoid needing to do anything more complex than that. (Scanning I've always done with a USB stick plugged directly into the printer.) Things kind of got worse again in recent years with the removal of the standalone GUI for administration in favor of a web interface, and various ongoing modularization efforts, in theory cups3 will work even better and only support IPP/AirPrint: https://openprinting.github.io/current/#the-new-architecture...
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.
> In part II of this series (date TBD since there’s another disclosure in process), we’ll see how to use these new bettercap modules (not yet released) to attack Apple macOS.
> I personally haven't printed anything for a long time, so I might've been biased in my reply.
Huh. I print less and less since college, but it honestly hadn't occurred to me that you might be a desktop Linux user who just doesn't print anything.
> There at printers that let you send a pdf directly to their ip address, ones that take in usbs, etc...
> As another thought, why does it come by default on most distros given its history?
I assume because people who do much printing definitely want to print in a 'normal', way, directly from applications. Isn't CUPS the only game in town there? That adds up to a lot of inertia. CUPS is mature and featureful and has been around for a long time, plus is integrated with the rest of the stack and all the applications, and it has no direct competitors on those platforms, as far as I'm aware.
Maybe Red Hat would be interested in producing a CUPS replacement, but they may also feel like for Fedora users and desktop users of Red Hat, SELinux and occasional emergency patches is good enough for what is ultimately not their core audience, as well as a hell of a lot cheaper and more politically feasible than a from-scratch rewrite. Idk who else would likely be interested in funding such a project.
> why does it come by default on most distros given its history?
Most distros are made by some high schooler as a weekend project. Fork Ubuntu, add some wacky experimental GUI, done.
And the distros that aren't like that are made by big corporations who only care about securing servers and kiosks, home desktops really aren't their concern.
Fair, but do people print away from home very often? I’ve never printed anything outside of home since high school, but maybe I’m an outlier.
Maybe a better question, would intentionally adding a printer at home and a printer at the office be that large a barrier?
Maybe we wouldn't even need to drop auto discovery. Maybe it could work more like Bluetooth and only broadcast or accept connections while it was actively searching.
If you mean use someone else’s printer, I do it occasionally. Usually TTRPG character sheets. I am so happy AirPrint is common now. Makes my life easier.
If you mean send something from outside of my house to my house, I’ve done using a vpn.
Tried it out, looks like at least on Debian the filter gets invoked with limited user privileges, so not world-ending, but still bad. And it does require user interaction, but my gut feeling is that this can be bypassed with some cleverness.
However, this is only for this particular exploit. The behaviour where cups-browsed automatically downloads and installs printers from random untrusted places on the internet is insane, especially as it does it for all printers it discovers on the local network by default. At minimum anyone on a LAN can cause a DoS type attack against all Linux workstations on the same LAN by just advertising a few million printers via zeroconf.
Irrespective of the severity assigned it's a good and simple case study for any programmer, engineer or not, building drivers and low-level stuff or not. Alongside it, and the iconic "Smashing the Stack for Fun and Profit", reading "The Bugs We Need to Kill"[1], makes a programmer much more aware that every program is prone to manipulation via its inputs.
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.
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?
Is that an exact quote? He says that he disclosed it now because there was a leak and "all vendors that bothered participating agreed on today at 20:00 UTC".
> vulnerability researchers justifying bad behaviour because they find a vulnerability in code
This is an extremely bad faith take that makes me irrationally angry to read.
He's not using bad code as a reason to engage in bad behavior, he's using bad responses to responsible disclosure. Read the section under "Personal Considerations". It only took him two days to find the problem, but 22 days to get developers to admit there's a vulnerability, even when shown PoCs.
Imagine finding a vulnerability, responsibly disclosing it, being told "meh, not an issue", responding with a PoC showing full code execution, and still being told "meh, not an issue".
> Imagine finding a vulnerability, responsibly disclosing it, being told "meh, not an issue", responding with a PoC showing full code execution, and still being told "meh, not an issue".
I would still want to be responsible. I shouldn't get to choose to be irresponsible when I have a bad experience. Then, naturally when the time is up and the disclosure happens according to the timetable, I would be the side looking much the better from it. As such behaving as he did and justifying it in that way is illogical.
I speculate that maybe the reasons he gave may not be entirely the whole story because he would have looked better responsibly disclosing, but its important to note that he doesn't blame poor code, thank you for the correction. And I am speculating for the reasons. Maybe in the future I shouldn't.
Responsible Disclosure has two forms: Coordinated disclosure where the vuln is disclosed to the vendor with a time limit for public disclosure. Full disclosure, where the vuln is disclosed to the public so they can take mitigation steps.
Irresponsible disclosure is selling the vuln to criminal groups or intelligence agencies.
Disagreeing with someone's decisions is not a valid justification for misrepresenting their motives.
I agree with you, it's kinda shitty, but I get where he's coming from. It's incredibly frustrating to want to improve the security of the world, but when developers have too much ego and push back against claims of vulnerabilities in the face of proof, well...every hero either dies or lives long enough to become the villain.
I've experienced it first-hand at a previous job. I found a buffer overflow in some firmware, and engineering just said "Meh, at worst you'll just segfault the device, and the user can just reboot". The fix would have literally just been a two-line buffer length test that throws a 400 Bad Request (It was an embedded web server written in C, with the vuln being in an XML parsing library), but I had to go through the effort of taking that bug and learning ARM assembly and return-oriented programming in order to create a PoC before engineering decided to fix it.
I suppose I should be happy, though, as that learning experience was the cannon that shot me from just being a test engineer into getting into AppSec.
I genuinely liked your opening statement (disagreeing...)
I am sorry to hear you had such a raw experience. Maybe you were dealing with pretty clueless engineers, since most do realize a buffer overflow should be treated exploitable unless proven otherwise. I've had better experience trying to argue the cost of fix -- it being pretty low was incentive enough for engineering to fix it.
That said, I am worried evilsocket may not be taken seriously next time he finds a vulnerability with CVSS 9.9. To some extent I am surprised by his argument on not knowing CVSS scoring rubrik. There may have been language barrier at play as well, leading to some of his sentences coming across as more abrasive than they should have been.
Yes, I can totally empathise with him too. I've behaved in emotional ways in with frustration because of code (but thankfully not in a public way with certain standards of behaviour). Let's hope he can learn from it. It's hard to act professional when acting alone and outside and against the so-called "real professionals".
Ultimately it's about trust. Perhaps these organisations have become too large and uncaring or maybe we have become too impatient and frustrated. I don't think anyone wants to see researchers not responsibly disclosing as well as companies irresponsibly interacting with external researchers who just want to help. It's easy to this as a path from white to black hat.
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.
> After some googling I found out that cups-browsed is indeed part of the CUPS system and it is responsible for discovering new printers and automatically adding them to the system. Very interesting, I had no idea Linux just added anything found on a network before the user can even accept or be notified. The more you know!
I don't know, last time i bought a new printer i plugged it into my LAN and my Apple machines automatically showed it to me and I could print to it.
Is there a recommended (best practice) way to nmap scan your network for vulnerable machines, just to be safe?
From Red Hat's statement:
> Red Hat rates these issues with a severity impact of Important. While all versions of RHEL are affected, it is important to note that affected packages are not vulnerable in their default configuration.
Basically, Red Hat machines aren't vulnerable unless "the cups-browsed service has manually been enabled or started."
And if the target is running CUPS on that port it will reach out to `myserver:PORT` and POST some data. The downside is you need to have a server running that can accept inbound requests to see if it connects back.
A fair point, although nmap does list results as "closed", "open" or "open/filtered".
Which can be ambiguous if the port is open or firewalled.
However, if the nmap reports that port is "closed," it most likely is:
Starting Nmap 7.92 ( https://nmap.org ) at 2024-09-26 20:02 EDT
Nmap scan report for [host] (localip)
Host is up (0.00084s latency).
PORT STATE SERVICE
631/udp closed ipp
I'd add that GP specifically requested an nmap command.
All that said, you're absolutely correct and if nmap returns something like this:
Starting Nmap 7.92 ( https://nmap.org ) at 2024-09-26 20:04 EDT
Nmap scan report for [host] (localip)
Host is up (0.00058s latency).
PORT STATE SERVICE
631/udp open|filtered ipp
then further poking could be required, as you suggest.
I would point out that cups-browsed isn't really necessary unless you desire to have printers automatically added without any user interaction. Which is poor opsec in any situation.
If we're talking about a corporate environment, adding printers can be automated without cups-browsed, and at home or in the wild (cafes, public wifi, etc.) that's an unacceptable (at least from my perspective) risk and printers (if needed in such an unsecured environment) should be explicitly added by the user, with manual checks to ensure it's the correct device.
As such, rather than checking to see if cups-browsed is running unsecured, simply check to see if it's installed:
This vulnerability seems to be pretty hard to actually exploit, but for those of you who are running Ubuntu on their desktops, consider enabling a firewall, which is as easy as:
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.
You are right of course, but the default policy can be changed using "ufw default allow incoming", making "deny" necessary. You might do it on a laptop/workstation (in a network firewalled from the internet), though it doesn't sound like a great idea to me.
Being pedantic is rarely helpful, especially when the drive to correct people means you rush and neglect to be correct, as you did each time.
There’s nothing magic about configuration files. Any time you are making changes which could impact a system’s ability to restart, you want to test them when you’re ready to fix a problem rather than waiting for the next security patch, power outage, etc. It’s more likely to make mistakes when editing config files by hand but it’s not the only way, and since it’s so very easy to check the argument against doing so is very weak - being confident you haven’t made a mistake is worth the second it takes.
“Good practice” is an argument, but it’s at a different level. Any field has lessons drawn from collective experience, and while those are never perfect and change over time they are a convenient shorthand for things which usually aren’t worth spelling out in detail every time. We say it’s good practice to have backups because most people only need the reminder, not a three page discussion.
You're free to restart anything you want, of course. Reboot the whole machine every time you change anything, that way you'll be sure. I am not stopping you, and in some cases it can be useful to make absolutely certain.
I only pointed out that "ufw reload" is not necessary to make "ufw allow/deny/delete" take effect. Multiple people might not have known that, judging from the upvotes I got. And now I find I have to justify myself. Is that being "pedantic"? Am I the one "rushing"?
I don't see a reason why reload should be "good practice". If ufw or your config is buggy, it is very possible for the rules not to apply at next boot, when iptables is reset. If this is critical, reboot and do a test connection.
There used to be a timeframe (before like 2020) where you could use network printers without any extra software: Open your Document in Firefox, print to postscript, and then netcat that postscript to your network printer port 9100. This is the "AppSocket" protocol.
Unfortunately, Firefox removed that feature, and port 9100 is now clobbered by the Prometheus node exporter. If you accidentally add a AppSocket capable printer to Prometheus it will print out HTTP headers every other minute.
The good times are over, but on the other side, having to print something has gotten quite rare.
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.
I am slightly confused. If I am using a linux laptop with cups do I need to do anything besides update? Is there a sane way to print from the linux desktop. I unfortunately need to regularly print, and often from public wifi.
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.
This is a misunderstanding of the vulnerability. The problem isn't with the print server. It is with the printer discovery mechanism, cups-browsed. That is the service that listens on the entire network, because it's designed so that LAN printers can advertise themselves to your system.
In that case one can disable it until it is patched assuming there isn't a udev rule that re-enables it. I stay clear of systemd these days so I don't know.
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:
I checked 5 linux desktop/laptops here and none of them had cups-browsed or port 631 exposed. They are all able to print to a network printer. The vulnerability is real though perhaps the impact is exaggerated. Distros that tend towards installing a minimal selection of packages and services are less exposed.
Maybe the report was overblown, but I found it amusing that CUPS related facilities is shipped and activated by default in a lot of Linux distros (including Gnome Fedora in my case). I've never printed anything on this computer and yet there is this `cupsd` process running as root and listening TCP port 631 on local interface.
OK, sure, the program itself maybe safe (enough to run with root while listening a local port that everybody uses this computer can access), but is it really THAT evil if you don't run it 24/7 and instead only enable it when the user is actively using it?
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.
I don't believe this warranted all the fearmongering even if the intention was to get more attention to it and a faster resolution process, it's not far from cry wolf. Initial CVE scores are very arbitrary. CUPS is a well-known liability when exposed to unsafe networks. CVSS scores seem far from perfect. The WebP zero-day, a zero-click vulnerability that was being exploited in the wild and affecting nearly every user device made in the past decade, most of which will never be properly patched from it, received an initial 10.0, and decreased to a meager 8.8 (CVSS:3.1, and would be higher using 4.0).
The problem isn't CUPS itself, which is not made to listen on all interfaces by default. The problem is the printer discovery service, cups-browsed, which listens for any printer on the LAN (or any attacker anywhere) that advertises itself to it and automatically registers that printer in your system.
Whether it's a good idea to have a service like this is highly debatable, but if it is added, it has to listen to all requests from anywhere (and the firewall port for it has to be open), otherwise it's entirely useless.
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.
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.
Sure but security isn’t about being 100% protected which is impossible, but lowering your attack foot print. Unless you have a ton of people hooking to your LAN regularly then this still greatly lowers you chances of getting hit with this particular security flaw by people on the WAN
A useful target might be university networks, although IIRC our university printers weren’t available for discovery. Instead we would send our documents to a special email that would forward it to a local print server so we could get charged for it.
I remember there was some like viral marketing thing some company did a while back where they had a website where they had a webcam pointed at a printer, and anything printed would go on a conveyer belt and fall into a literal dumpster fire. Users could submit stuff on their website and see it printed and burned live.
...anyways, maybe they were vulnerable to this attack at the time?
Everybody saying this is nothing burger is absolutely wrong. This is not overhyped. A lot of comments like, well my distro doesn't do this, and well yeah nobody uses printers anymore. A print server is design to be exposed. Office networks will use one and they have important data. You would think there would be some kind of hardening.
So just to make sure I understand correctly, this is a nothingburger, right? No important server has a printer attached. Any basic firewall would block this traffic.
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.
Likely no good reason. But he seemed to have identified many many systems that were, inexplicably, exposing port 631 to the internet. There is some reason people are doing it and, given the number of target systems, it must be some sort of default configuration.
> "This thing is packaged for anything, in some cases it’s enabled by default, in others it’s not, go figure . Full disclosure, I’ve been scanning the entire public internet IPv4 ranges several times a day for weeks, sending the UDP packet and logging whatever connected back. And I’ve got back connections from hundreds of thousands of devices, with peaks of 200-300K concurrent devices. This file contains a list of the unique Linux systems affected. Note that everything that is not Linux has been filtered out. That is why I was getting increasingly alarmed during the last few weeks."
The likely target that emerged in my mind reading this is mom and pop point of sale systems.
The operators of such systems are completely oblivious to such risks, and the underpaid PoS software support team following a script to restart CUPS probably are as well.
The 9.9 issue is the foomatic-rip vulnerability; not cups-browsed listening on 0.0.0.0. See here:
> 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.
I believe you'd still need cups-browsed installed, enabled & configured to accept remote printer broadcasts, _and_ have foomatic installed locally in order to get hit by this.
Modern version of cups will basically only talk to "driverless" IPP Everywhere printers, which all understand a common set of raster formats and hence have no need for printer-model specific software like foomatic-rip to be installed. They do this via mDNS, which means you don't need cups-browsed to be installed either.
You do, until someone finds a way to exploit the other buffer overflows. But also, this attack is persistent: you get infected without any interaction at the coffee shop, and two years later when you print something at home on your well secured network: BAM!
Uh, how? Unless somehow it stays around even though you've left the network (which I didn't think happens, but I could be wrong), this lasts just as long as the mDNS attacking server is on the network?
This to me feels like the author missed why the system was set up the way it was, and therefore doesn't present useful solutions.
The attacker sends a malicious UDP datagram to the target computer, telling it is a printer available at ATTACKER_CONTROLLED_URI.
The vulnerable computer receives this packet and proceeds to download the "printer information" (attacker-controlled printer scripts) from ATTACKER_CONTROLLED_URI and store it in a PPD file as an available printer, potentially overwriting an existing printer.
There is no user intervention needed, nor any notifications to the user, up to this point. The PPD files are persistent: they will stick around ~forever on your system until some other printer replaces them, or you manually delete them.
Whenever you want to print, CUPS looks for all the PPD files currently on the system and provides print options based on them. If you choose to print using the malicious printer (which might look like one of your known printers), the information in the attacker-controlled PPD file will be used by CUPS, including Foomatic scripts that can run more or less arbitrary code with root privileges.
The biggest issue with all of this is that Linux doesn't distinguish between trusted LANs, where arbitrary printers connecting to you is actually a pretty nice feature; and public untrusted LANs, where this is DEFINITELY not a good idea. Also, the fact that your printer infra can run arbitrary code as root, code supplied by the remote printer itself, is another level of crazy.
> Linux doesn't distinguish between trusted LANs [...] and public untrusted LANs
Gotta be the annoying and point out here that Linux is a kernel. Fedora Workstation, for instance, has firewalld installed & enabled by default, which does apply different policies to different network zones. Hook a default system up to a hostile coffee shop, and TCP/UDP ports <= 1024 are blocked by the default FedoraWorkstation zone. NetworkManager connections have a 'zone' property that the user can change to 'home', 'trusted', etc.
> Also, the fact that your printer infra can run arbitrary code as root, code supplied by the remote printer itself, is another level of crazy
Only, it seems, if non-default legacy printer drivers (foomatic) and discovery services (cups-browsed) are present. And doesn't cups run backends as an unprivileged 'lp' user? And confined by MAC (again, in the Red Hat world, SELinux confines it to the cupsd_t domain). So not _that_ crazy.
Disabling foomatic seems hard since the PPD can be distributed by the attacker and foomatic-rip is part of the cups-filter package. But yes, lp user + SELinux should be enough to make this not a 9.9.
I actaully didn't realise that foomatic is part of cups-filters now?! On the other hand - it's only 'activated' by cups-browsed, if I understand correctly, at least by the currently disclosed set of vulnerabilities... let's hope an attacker can't craft a printer that will trick cups itself into configuring a dodgy print destination...
Wait, this is a joke, right?
> 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).*
(emphasis mine)
There's no way this is 9.9 when Heartbleed was just 7.5...
EDIT: Wanted to add why I think he has overblown this way too much. His original tweet stated "* Unauthenticated RCE vs all GNU/Linux systems (plus others)" but as we can see this isn't nearly the case as on a lot of distros CUPS only listens on loopback or isn't installed at all.
Another point:
> Full disclosure, I’ve been scanning the entire public internet IPv4 ranges several times a day for weeks, sending the UDP packet and logging whatever connected back. And I’ve got back connections from hundreds of thousands of devices, with peaks of 200-300K concurrent devices
If I'm understanding this correctly, he only found 300 thousand open CUPS instances in the whole public IPv4. Remember - the CUPS server needs to receive a print job in order for the RCE to happen, which I doubt most of these instances will get.
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.
CUPS 3 goes the other way, relying solely on IPP for discovery and autoconfiguration.
> the entire `cups-browsed` daemon should probably stop existing
It's a legacy component that you don't need with modern printers - cups itself only support IPP Everywhere (printer discovery via mDNS) these days.
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.
Thanks, I missed that. But that still leaves us with only 300 thousand exploitable instances in the whole public IPv4 address space. This is nowhere near a universal GNU/Linux RCE. Of course it's still a big deal to those affected servers, but it's nowhere near even RegreSSHion.
No, the author said that the peak concurrent connections was 300k. That tells us there are at least that many vulnerable hosts publicly exploitable, but there could be many more that are transiently exploitable.
Also, this attack is easily triggered from any LAN, such as an airport or university or corporate or coffee shop network. And it is persistent: the attacker persistently registers a "printer" on your system (potentially overwriting a real printer that you actually have), and later when you print, even disconnected from the internet, you can trigger the RCE.
Ehh most public wifi spots segment clients... You will be unable to send traffic to neighbors...
If it's an open network, and there are still quite a few of those, it's not hard to broadcast packets over the air and fool the receiver into thinking they're coming from the connected AP.
Most run by commercial enterprises do, because they have teams running them that care about security.
Your average non-large-brand coffee shop or ho(s)tel? They stick some cheap ass router in and disable the wifi password to get a public wifi for their guests.
Reminds me when used to redirect or/and replace images on sites in cafés with zANTI.
That's nearly as many as Code Red and roughly 100K more than SQL Slammer.
Add every macOS-running device to the picture (who disables cupsd?)...
My mac right now running Sonoma 14.6.1, with no system modifications or MDM:
cupsd is not running. If I go to print something cupsd will start up, and after a while of idle it'll shut down again.The socket activation thing it has with systemd as well, but I don't know if there are facilities for automatically shutting it down like that as well.
That's a nice touch, and it'd be cool if Linux distros added that.
Same here. Also, using netstat for the PID you can see that it's only listening on localhost ipv4/ipv6.
Generally, CUPS on a Mac is bound to localhost. It is highly atypical for a Mac to make it so any computer on the internet or even local network can make requests to its cups server.
The problem isn't CUPS itself, it's the automatic printer discovery mechanism. That's cups-browsed on Linux, not sure how it's achieved on a Mac.
And the printer discovery service can't be firewalled: by definition, it has to listen for outside connections to be in any way useful. This is where things like Windows' trusted VS untrusted networks make sense: it's perfectly nice to allow printers to register to your system on your home network, it's a horrible idea when you connect to an airport wifi.
CUPS is also part of iOS and iPadOS.
If those ship cups, why do they require special AirPrint-compatible printers?
I dunno. I assumed that
> The standards-based, open source printing system developed by Apple for iOS®, iPadOS®¹
ships on iOS® and iPadOS®.
But maybe it doesn't. ¯\_(ツ)_/¯
In seriousness, exposing only a very limited interface to a flexible, capable system seems to me very on-brand for Apple.
Maybe they don't iOS and iPadOS to be of the kind of platform where one thinks about drivers, even if exposing CUPS features to users would let users accomplish more without much trouble.
Or maybe they see printer drivers as essentially a legacy feature in the face of a 'driverless' future.
Not my cup of tea, but both seem like things leaders at Apple would do/think.
--
https://www.cups.org/
CUPS predates iOS by a decade and wasn't developed by Apple.
Apple CUPS is a distinct distribution of CUPS.
Yes, and CUPS was used on macOS, from which iOS was forked before Apple releases the first iPhone. And from that same year (2007) until 2019, Apple employed the creator and chief maintainer of CUPS, which is presumably how they got their hands on the cups dot org domain. Then (as is typical of Apple's treatment of open-source), Apple stonewalled outside contributions and public releases became increasingly sparse and insignificant. So the creator and longtime ch8ef maintainer of CUPS, now outside Apple, created a new fork under the OpenPrinting banner. Thus CUPS became 'Apple CUPS' and the 'CUPS' everyone else cared about was now OpenPrinting CUPS.
My point was that Apple's language on the website indicates that they probably use CUPS on iOS and iPadOS, not that that language describes CUPS' origins or is informative about the nearly three decade history of of the software or the current landscape of its forks. (Although in fairness to Apple here— a company of which I am not a fan— 'developed by' doesn't mean the same thing as 'authored by' or 'created by'.)
macOS has a firewall on by default.
That doesn't help if the goal is to allow printers to register automatically to your system.
Are you sure? E.g. the blog post mentions a one-byte read overflow, which is unlikely to be directly exploitable.
It also mentions:
> I can tell you that there’re other, more easily exploitable code paths going on, not just in the discovery mechanism - also reported and ignored. To this day they have not been acknowledged or patched.
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.
It's RCE (as the lp user, if I'm not mistaken) with user action, and only if the firewall isn't blocking required ports. Most systems, even most systems with CUPS installed, never print anything. The number of systems with no firewall (where "firewall" here could just be NAT) that actually print something is even smaller.
> 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.
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
This is strictly a miscalculation/fudge.
In isolation (which is what CVSS is all about) this is not a network exploitable vulnerability, even if you can craft an attack chain which exploits it over the network.
So:
AV:N -> AV:L - reason above
AC:L - correct
PR:N -> PR:L - to exploit this you need to get cups to process a PPD file. Ignoring how it got there, writing a PPD file requires low privileges on the local machine (unless I'm wrong and you can't add a printer to cups as a local user by default, in which case this becomes PR:H with an overall score of 7.7). These might be fulfilled by another component of the attack chain, but again, you need to strictly think in terms of the vulnerability in a vacuum.
UI:N -> UI:R - that a user must perform a task after you begin exploitation in order for the exploit to complete is a classical example of required user interaction
S:C - correct, attacking cups and getting root on the whole machine is considered a scope change
C:L -> C:H - Running arbitrary code as root on a machine is a total breach of all confidentiality of the local machine, so not sure why this was marked as low.
I:H - correct
A:L -> A:H - Running arbitrary code as root on a machine lets you do anything to completely disable it permanently. Availability impact is high.
In summary a score of 8.2 (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H) for CVE-2024-47177 in a vacuum.
But it seems like User Interaction is required.
Printing something at some point arbitrarily later on the system is almost certainly not classed as User Interaction in this sense.
Yeah, I guess you're right, for CUPS it might be 9.9. My other added points about it being a vastly overblown exploit still stand.
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.
It's not that. Apparently, several major Linux distros, and the cups-browsed developers, have decided for people that any device on the internet should be able to connect to their system as a printer.
How do they get around the built-in firewall that's been standard on home routers for the past 15 years?
Firewall lets it through: cups-browsed explicitly listens for printers advertising themselves. If it's firewalled off, how can it receive the printer advertisements?
I don't know what default firewall rules are configured, but on distros that run it I'd assume it's allowed through, otherwise no reason to run it.
That should protect you from Internet-based attackers, but it doesn't protect you from attackers on the same LAN. For example, if you're in a coffee shop and using their free public wifi, an attacker in that same network can trigger this.
The I in IPP stands for 'Internet'. I guess some people really mean it.
Maybe some may fall into the IOT/Embedded category. Wouldn't be very surprise if i.e. a cheap wifi camera have cups installed just because and jumps out in this scan.
Or, there are a whole lot of sites running honeypots. But it's still probably a very large number.
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
> 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.
Heartbleed was a different CVSS version.
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:
If that's the case, this would really be a testament to SELinux and the final blow to AppArmor or whatever Canonical is shipping nowadays (clearly useless).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/
Evilsocket is a known hacker. They made for example Bettercap (Pwnagotchi), Opensnitch, and a myriad of other tools. They don't need fame.
People who already have some level of fame often feel pressure to keep meeting "expectations".
Red Hat is the company which first assigned a score of 9.9 fwiw, I think they would've mentioned if it didn't affect RHEL/Fedora?
The first thing many do in the real world, after installing RHEL or the free derivatives is ... turn off SELinux.
It is a great way to show which people care about security.
I equate (and I am likely not alone) that this would be a modern equivalent of chmod -R 777 / in early Unix computing.
Use of AppArmour/SElinux is probably a good filter during an interview to determine if a person is a good fit for a security conscious position.
Hard disagree. FS permissions take like 5 minutes to explain and then you maybe need another 30 minutes in total to try around and get a hang of it. I've given up on selinux every time I've tried to make sense of it. Open 3 different tutorials, have 3 totally different approaches to it.
I guess if you only install core packages on redhat and never touch a single config file it might work OK even for the average Joe.
I found that for me, SELinux is best mastered by reading the documentation. Most tutorials I read when trying to make custom policies and monitor how policies were working, were hot garbage written by people who were just reading other people’s tutorials. SELinux solves problems orthogonal to FS permissions, and use cases that FS permissions alone don’t address.
It was a bit tough at first but writing your first SELinux profile is a fantastic way to make it approachable. YMMV, of course.
I guess I must be wrong. So many people disagree with me I must be an idiot.
You can write and understand llms but not selinux policies..
You are right, the crowd has spoken. Thank you for the education hn.
If you want to get fired, sure!
> The first thing many do in the real world, after installing RHEL or the free derivatives is ... turn off SELinux.
The people with port 631 publicly reachable didn't configure their firewall either (neither at OS level nor at infrastructure level) so what now, firewalls are useless?
Cups needs permissions for Foomatic and some printing filters.
Are you suggesting that people should not report remote command execution vulnerabilities when such vulnerabilities are successfully stopped by SELinux?
Also, why do you think that seeking recognition for your efforts a bad thing?
> Are you suggesting that people should not report remote command execution vulnerabilities when such vulnerabilities are successfully stopped by SELinux?
No, I'm suggesting that only testing on system shipping weak protection systems and poor defaults is misleading.
> Also, why do you think that seeking recognition for your efforts a bad thing?
It isn't by default, but it can become a bad thing when you overstate the importance of your finding: see my previous line in this comment and add the fact that this guy picked a cve score of 9.9 where heartbleed had "only" a 7.5 score -- but heartbleed affected pretty much everybody in the industry.
> But here’s a screenshot from the VINCE report of the initial CVSS scores, including the 9.9, being estimated by a RedHat engineer (and also reviewed by another one)
> As I said, I’m not an expert, and I think that the initial 9.9 was mostly due to the fact that the RCE is trivial to exploit and the package presence so widespread. Impact wise I wouldn’t classify it as a 9.9, but then again, what the hell do I know?
He did _not_ pick the score.
> No, I'm suggesting that only testing on system shipping weak protection systems and poor defaults is misleading.
But then he would not have found and reported the vulnerability, yet it would still exist and affect people.
Once the vulnerability was discovered it doesn’t matter if one operating system or the other has protections in place that will stop it. What matters is that the code is vulnerable and that there are people who are not protected. Proving that it is not exploitable on systems configured a certain way does not invalidate the original finding.
Anyone exposing CUPS to the internet is living a level of not giving a fuck that CVEs cannot reach.
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.
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!
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.
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.
FWIW, my team is me and maaaybe 30% of another guy, but point noted. :-)
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.
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.
This is why on public servers I block everything inbound and only allow specific needed services through.
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. ]
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
Why does it even listens in UDP at this day and age?!
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.
DNS is actually UDP/TCP. It’s probably required for receiving unicast messages, if it’s using DNS-SD
To receive multicast messages, probably.
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.
OpenSUSE
But it looks like cups-browsed is only needed on the Internet; locally you only need mDNS.
mDNS doesn't allow the printer to register itself to your system, which is the (highly dubious!) purpose of cups-browsed.
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.
MX Linux
on popOS I see 0.0.0.0:*
I'm not sure why it deviates from Debian and Ubuntu which its based on though
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.
oh sorry yeah I copied the wrong column. the correct column is `0.0.0.0:631`
Who doesn't block all unneeded ports on an internet facing server or have it behind a firewall of some sort?
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.
Well lots of people crash 600HP cars right after they buy them. If you haven't done your homework, you'll learn quickly.
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.
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.
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.
And this is why Microsoft force pushes updates. I think when Linux desktops become really popular there is quite a worry if the users simply do not update them regularly enough. Or if they are not secured in most ways by default.
I'm pretty sure all major distros configure it to listen locally instead.
cupsd is configured to listen locally, but cups-browsed has to listen on the network to do its job (network printer auto-discovery)
> 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?
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...
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.
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.
> I would hope that a default [OS] desktop installation would be secure enough to set up without a firewall.
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.
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.
Honestly, this is why firewalls exist. This really isn't problem for anyone with basic computer hygiene.
The prevalence of attitudes like this in the Linux community is why the year of the Linux desktop will never come.
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.
Why isn't the firewall on by default on desktop systems?
It is ? At least on Fedora Workstation for example, Firewall (controlled by firewalld) is installed and enabled by default.
Bear in mind that the default FedoraWorkstation firewalld policy does not protect TCP/UDP ports >= 1025.
Fortunately, in this case, cups-browsed uses port 631/udp :)
Because you don't need a firewall on a sensibly configured desktop computer.
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.
That attitude was popular in the 90s but any definition of “sensibly configured” in this century involves a firewall.
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 encryption 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.
And, for some utterly and completely absurd reason, CUPS runs as a system daemon instead of a highly sandboxed user program.
On Ubuntu, both. A system daemon with interesting interactions with avahi-daemon and colord, and a somewhat sandboxed user program, just so Chrome is not overly inconvenienced by its snap sandboxing. But wait, there is more: The login & lock screen also runs the whole glory of GNOME.. to query printer settings. So you can have those sweet, sweet "new printer" notifications overlaid while inputting your password. Or whatever else "your" printer needs to add there.
FWIW, on OpenBSD, cups-browsed is not on my system, but there are some cups files.
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.
It's a spooler for a printing system that supports concurrent job submission, potentially among multiple users. It's going to have to achieve serialization some kind of way.
Why does it need to run as `root` user and not `cups`?
As long as that user can talk to the printers' device nodes (and/or the network), it needn't so far as I know.
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.)
Binding to ports under 1024 traditionally requires root privileges. (These days of course that isn't quite as true as it used to be.)
It's common practice to open the socket to start listening on the <1024 port, then drop the root privileges and continue as a different user.
On a modern Linux system, it’s better to use the CAP_NET_BIND_SERVICE capability instead. Then you don’t need to start the process as root at all.
Why on Earth do ordinary systems need CUPS binding to a port at all?
They don't. cups-browsed is a legacy component that isn't needed on ordinary systems, which outsource printer discovery to an mDNS service such as avahi.
They don't need. Want, for listening to network printers announcing themselves. It's a very bad system, even then.
Have you ever seen a network printer announce itself by talking to a print daemon on port 631?
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.
I believe these vulnerabilities only allow RCE as the 'lp' user (which is able to access parallel ports and USB devices that identify themselves as printers). In addition the process will be confined by MAC policies (e.g., on Fedora/Red Hat I think they're confined by cupsd_t).
I have never, in the entire history of my usage of desktop systems, wanted my system to spool out a print job on behalf of a non-current user. Nor have I wanted my system to continue servicing my print queue after I log out. To the contrary: it’s incredibly annoying when the queue glitches out and then my print jobs show up in the printer tray after I’ve left.
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.
This is the worry. It seems like a really unnecessary privilege escalation.
It's because of the frankly idiotic idea of persistent print queues. If you want to have this artifact that survives a user session, then the print subsystem needs super-user abilities.
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.
No, persistent print queues can be implemented without cups running as super-user.
I'm a little confused why this is even an issue. Persistent queues have been an option since the days of Windows 9x.
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.
Windows 9x printing was every bit as bad as CUPS.
The point was about the retention of print jobs in queue, that it was a concept and option since the mid 90s.
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.
Link to the OP for those that haven't seen it: https://x.com/evilsocket/status/1838169889330135132
Hyped it up to be some massive thing but it turned out to be a massive nothingbuger for me at least
It's always funny to me how cybersecurity always seem to attract people with a ... certain sense of ego.
> pretty much only got patronized because the devs just can't accept that their code is crap - responsible disclosure: no more.
I can think of another reason they got patronised.
They claim to not be a cybersecurity pro
Non-loginwalled link: https://threadreaderapp.com/thread/1838169889330135132.html
Yeah tbh it's not as bad as he claimed. I doubt this is actually rated 9.9:
>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
Or any malicious user on the airport wifi. The compromise will linger until however many weeks later when you decide to print something...
Keep in mind that you still need send a print job to the fake printer to trigger the exploit. If you send the job to your real printer, nothing happens.
The exploit allows an attacker to overwrite your real printer with their fake printer.
Not using the "WAN" attack if you are using a firewall config that stops that on public wifi.
I do not understand how the mDNS entry point works.
i knew there was a reason i blacklist unsolicited/unauthenticated UDP inbound.
Depending on your interpretation of the Scope metric in CVSSv3, this is either an 8.8 or a 9.6 CVSS to be more accurate.
In summary, there's a service (CUPS) that is exposed to the LAN (0.0.0.0) on at least some desktop flavors of Linux and runs as root that is vulnerable to unauth RCE. CUPS is not a default service on most of the server-oriented linux machines like Ubuntu Server or CentOS, but does appear to start by default on most desktop flavors of linux. To trigger the RCE the user on the vulnerable linux machine must print a document after being exploited.
Evilsocket claims to have had 100's of thousands of callbacks showing that despite the fact most of us have probably never printed anything from Linux, the impact is enough to create a large botnet regardless.
Universities are full of people with Linux desktops with public IPs and that are printing all the time: papers, their own and other's.
Yes, good point, university networks are particularly vulnerable.
Great opportunity to expand the Sci-Hub effort /s
Having a public ip address doesn't always mean there's no firewall in between a pc and the public internet, ideally with sensible default rules. It's not 1996.
And sorry if I'm being a bit harsh on this, but this point comes up every time when ipv6 is mentioned, by people that clearly don't understand the above point.
The point is that, if printing works for those people, then we know they have this port open, at least on the university network. So even if it's not exploitable over the internet, it's definitely exploitable from the whole university network, which is almost as good as from the internet.
Just to add a datapoint to the previous comment, my large public US university hands out public IPs to every device on WiFi. If there is a firewall, it doesn't block 8080 or 22.
Yes. It's rather sad that so many people equate NAT with a firewall. Two totally different things. A firewall is good, NAT is annoying. We need to push IPv6 harder.
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
Because scores are kinda bullshit.
But real answer is well if you have arbitrary remote code execution you can also read memory, where as heartbleed only read memory... And the reality is same, you were safe from heartbleed if you did not use openssl, you are safe from this if you do not use cups. CVSS score does not take into account if the software is used or not.
I guess a part of the issue is that it was reported as a "9.9 severity vulnerability in Linux" in a bunch of places, which makes it sound incredibly severe, whereas a "9.9 severity vulnerability in CUPS" doesn't
I panicked a little when I heard the news as I run a cupsd open on the Internet. But as it turns out, the issue is misrepresented in headlines, just like here. This is not an issue in the core cupsd, but in a separate package/component, called cups-browsed. My distribution of choice for servers, Gentoo Linux, ships cups-browsed in a separate package which I had not installed, meaning I, as well as most other cups users that did not install this additional package, am not affected by this bug.
Saying that all systems running cups can be hacked is a misrepresentation of the scale of the issue.
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.
Resuming:
> 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?
I would rather expect this kind of change came later, when there has been a huge push to make the "linux desktop" more user-friendly.
1999 sounds like the time when people were a bit more expected to mess with config file and somehow always had a root terminal around. If anything, keep in mind that in 1999 it was still a rite of passage to have to learn how to write the X11 configuration file (what used to be xorg.conf)
I’d shift that a little earlier (XF86 autoprobing worked for a lot of hardware by the turn of the century) but especially also recognize the competitive environment. Mac, Windows, OS/2, etc. users had been using local network discovery since the 80s, and the people trying to popularize Linux on the desktop were all too aware of the “by and for computer nerds” reputation they were trying to shake, and a lot of people still thought about corporate networks as isolated enclaves where nothing too dangerous happened. The threat model for a lot of people, even server admins who should have known better, was more along the lines of “someone will print a picture of their butt on your desktop printer” rather than “your workstation is now being used to attack the accounting system”.
Used to be XF86Config (even on non-*86). Xorg came in something like 2005. These things are really pretty young still.
> That a lot is expected and taken for granted from the security researchers by triagers that behave like you have to “prove to be worth listening to” while in reality they barely care to process and understand what you are saying
The unfortunate reality is that for every well-researched report like this one, you get 57 low-effort spam reports that hope to extract a bug bounty reward, or get a CVE discovery listed on their resume. Especially with the rise of LLMs that kind of spam can easily trick you. It's a sad situation, but I don't entirely blame developers for being skeptic.
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...
While in this case distros include cups-browsed maybe as a feature, I always feel it's a bad thing Ubuntu/Debian (and maybe all deb-based distros?) automatically bring up almost all services upon installation. This means you can install a package and accidentially open another network service that's installed as a dependency.
You probably already know exim4 (to be fair it listens to only localhost by default, so maybe not a big deal). I just tried to install cups-browsed on one of my Debian machine, and it brought up two services that listens to 0.0.0.0 (cups-browsed and avahi).
This is not the case for Arch/Gentoo and CentOS-like distros.
The original CVSS score on Twitter indicated that user interaction was not required. However reading the RCE chain on the page says:
Wait for a print job to be sent to our fake printer for the PPD directives, and therefore the command, to be executed.
If Alice never hits print it seems like a print job will never be triggered. Am I missing something? I'm not questioning evilsocket, I'm trying to check my understanding.
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 is untrue that every buffer overflow can be exploited. We won't know whether these can be until someone tries.
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.
I agree that Alice just needs to print anything but that seems like user interaction required. Its also not clear if Alice has multiple printers defined does it matter which printer she selects?
The attacker can replace any and all printers, so not entirely. I'm not sure how the UI part of CVSS is specifically defined, but I think it's at least somewhat fair to call something the user is expected to do unrelated to the attack in any way "no interaction". Otherwise, it's like saying "the user has to power on their device and turn on their Wi-Fi for the attack to work, so it requires user interaction".
The question I had is whether the attacker can enumerate known printers, too. Replacement is a lot more damaging if they don’t have to discover the name of your default printer first.
The interaction question is complicated because there are three modes: the most damaging is when the attacker can trigger the exploit directly, since that’s where we start seeing worms and other untargeted attacks. The next level is where the attacker can exploit something the user normally does - hence the question about default printer replacement since that is something the user has done many times before and thinks of as safe. The lowest level of risk would be if they need to get you to click on a different printer: still bad but nowhere near as easy to exploit on a large scale.
She needs to print something using the fake printer. Nothing happens, IIUC, if Alice chooses to print a document with a real printer.
The attack can overwrite the real printer with a fake one.
Where did you see that?
Ctrl+F "replace"
in the middle of the alley
Every time I need to print something on MacOS I am reminded of how much I hate printers and any printer related software. I've been messing around with computers for 40 years now and goddamnit, every decade printers become more of a pain in the neck.
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.
But at least we got all the byproducts.
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.
Agreed, I ran several busy printers for a large department. The ljet IIIs were work houses and ran nearly forever if you used the recommended part replacement schedule.
We had a ljet III that outlasted ljet 4, ljet 5, and ljet 4000. Ljet 3 was the last with the HP print engine, afterwards they used Canon print engines.
The network interface was brittle, even a nmap would hang the printer. So we firewalled it off and used CUPS to handle postscript -> PCL. Sending only PCL to the printer (postscript memory and CPU is unbounded) made them faster and MUCH more reliable.
IIRC the Laserjet 4 had a much better warm-up time (and lower power consumption) by switching to a thin ceramic heating element rather than heating half the printer. But yeah anything after that is downhill.
It would be helpful to understand exactly which layers in the stack you think of as technically difficult.
do you mind lightly summarizing what technical problems make it more difficult? I'm assuming there are all sorts of things web-devs never even think about from that world.
Poor status, often a 1 line LCD says "processing..." and hangs infinitely.
Different handling of duplex, monitoring ink levels, file formats (PS? EPS? PNG? PCL? Which versions? Etc).
Issues with ink that expire by date, reduced functionality with 3rd party inks, not being able to print black even when only yellow is out of ink.
Different postscript versions and the nature of a language where CPU and memory use is unbounded means you get a nightmare of which files can print to which printers.
Most of our printer nightmares, at least the software issues, ended when we handled postscript -> PCL (a raster based format) on the server side.
Every printer vendor does things differently, every printer has different constraints and options? Too many standards?
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!
printing even works on linux now, thanks to stuff like Airprint and the support for it in CUPS
Yeah something like 10-15 years ago I thought for just the simple action of printing a file, it was way easier in Ubuntu than Windows, simply because they included a lot of drivers in the distro by default, while in Windows land I still had to visit the printer manufacturer's website for drivers -- or use the included CD! I try to avoid needing to do anything more complex than that. (Scanning I've always done with a USB stick plugged directly into the printer.) Things kind of got worse again in recent years with the removal of the standalone GUI for administration in favor of a web interface, and various ongoing modularization efforts, in theory cups3 will work even better and only support IPP/AirPrint: https://openprinting.github.io/current/#the-new-architecture...
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?
Heh, I've heard complaints about multi GB driver installs on windows, sounds worse to me.
Of course its CUPS.
Saying it affects all "Linux" systems is just wild.
Imagine even having that thing on your system to begin with.
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.
OP has promised to discuss macOS in part 2 of this blog post series. So sounds like the answer is yes.
https://github.com/OpenPrinting/cups-browsed/issues/36#issue... makes it sounds like most of them don't, and even if they do, it's sandboxed.
There may be something else for that.
> In part II of this series (date TBD since there’s another disclosure in process), we’ll see how to use these new bettercap modules (not yet released) to attack Apple macOS.
> 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.
Fair, I just don't print usually. Didn't think the phrase through too much. Sorry about that.
I've talked about alternatives in another reply, they do not offer the same flexibility as CUPS however.
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”?
That commenter is probably just someone who has never used anything but Windows on the desktop.
I run Linux and have been for 10 years. There have been many vulnerabilities with CUPS over the years and its generally known as being risky.
There at printers that let you send a pdf directly to their ip address, ones that take in usbs, etc...
CUPS does a lot of things, but for desktop use do you really need everything?
I personally haven't printed anything for a long time, so I might've been biased in my reply. So, I'm sorry if the comment was a too generalized.
As another thought, why does it come by default on most distros given its history?
> I personally haven't printed anything for a long time, so I might've been biased in my reply.
Huh. I print less and less since college, but it honestly hadn't occurred to me that you might be a desktop Linux user who just doesn't print anything.
> There at printers that let you send a pdf directly to their ip address, ones that take in usbs, etc...
> As another thought, why does it come by default on most distros given its history?
I assume because people who do much printing definitely want to print in a 'normal', way, directly from applications. Isn't CUPS the only game in town there? That adds up to a lot of inertia. CUPS is mature and featureful and has been around for a long time, plus is integrated with the rest of the stack and all the applications, and it has no direct competitors on those platforms, as far as I'm aware.
Maybe Red Hat would be interested in producing a CUPS replacement, but they may also feel like for Fedora users and desktop users of Red Hat, SELinux and occasional emergency patches is good enough for what is ultimately not their core audience, as well as a hell of a lot cheaper and more politically feasible than a from-scratch rewrite. Idk who else would likely be interested in funding such a project.
> why does it come by default on most distros given its history?
Most distros are made by some high schooler as a weekend project. Fork Ubuntu, add some wacky experimental GUI, done.
And the distros that aren't like that are made by big corporations who only care about securing servers and kiosks, home desktops really aren't their concern.
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.
> Do people have printers that move around all the time?
I suspect it's not the printers that are moving, but the laptops.
Fair, but do people print away from home very often? I’ve never printed anything outside of home since high school, but maybe I’m an outlier.
Maybe a better question, would intentionally adding a printer at home and a printer at the office be that large a barrier?
Maybe we wouldn't even need to drop auto discovery. Maybe it could work more like Bluetooth and only broadcast or accept connections while it was actively searching.
If you mean use someone else’s printer, I do it occasionally. Usually TTRPG character sheets. I am so happy AirPrint is common now. Makes my life easier.
If you mean send something from outside of my house to my house, I’ve done using a vpn.
Tried it out, looks like at least on Debian the filter gets invoked with limited user privileges, so not world-ending, but still bad. And it does require user interaction, but my gut feeling is that this can be bypassed with some cleverness.
However, this is only for this particular exploit. The behaviour where cups-browsed automatically downloads and installs printers from random untrusted places on the internet is insane, especially as it does it for all printers it discovers on the local network by default. At minimum anyone on a LAN can cause a DoS type attack against all Linux workstations on the same LAN by just advertising a few million printers via zeroconf.
Irrespective of the severity assigned it's a good and simple case study for any programmer, engineer or not, building drivers and low-level stuff or not. Alongside it, and the iconic "Smashing the Stack for Fun and Profit", reading "The Bugs We Need to Kill"[1], makes a programmer much more aware that every program is prone to manipulation via its inputs.
[1]: https://www.usenix.org/system/files/login/articles/login_aug...
> I had no idea Linux just added anything found on a network before the user can even accept or be notified. The more you know!
Windows does this too, I believe. At least it did it with a Xerox laser printer I bought and the Brother printer at my friend's place.
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.
This is a ridiculously over hyped vulnerability, the most over-hyped I've seen in a long time.
Still, kudos to the author who found it, it's going to definitely be a career boost with all the world is ending headlines.
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.
The author isn't really the one over-hyping it.
Same here. I don't need people overstating issues working for me. I'd never be able to trust anything this person says, in terms of priority.
Literally making things up, screaming his head off, crying wolf, "all linux systems" my ass. A horrible person.
You know some people actually take security seriously? Not this guy. It's all a personal hype vector.
From DEFCON 1 to “it’s absolutely nothing” in 5 hours
yeah i thought it was going to be something in tcp stack
This is a lot less "exciting" than the LOOK AT ME MOM I MADE AN EXPLOIT social media posts implied.
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?
Is that an exact quote? He says that he disclosed it now because there was a leak and "all vendors that bothered participating agreed on today at 20:00 UTC".
https://x.com/evilsocket/status/1839433162168181051
Anyway, I don't like his tone and he's overreacting imo.
>Is that an exact quote?
It is.
https://x.com/evilsocket/status/1838169889330135132
> vulnerability researchers justifying bad behaviour because they find a vulnerability in code
This is an extremely bad faith take that makes me irrationally angry to read.
He's not using bad code as a reason to engage in bad behavior, he's using bad responses to responsible disclosure. Read the section under "Personal Considerations". It only took him two days to find the problem, but 22 days to get developers to admit there's a vulnerability, even when shown PoCs.
Imagine finding a vulnerability, responsibly disclosing it, being told "meh, not an issue", responding with a PoC showing full code execution, and still being told "meh, not an issue".
> Imagine finding a vulnerability, responsibly disclosing it, being told "meh, not an issue", responding with a PoC showing full code execution, and still being told "meh, not an issue".
I would still want to be responsible. I shouldn't get to choose to be irresponsible when I have a bad experience. Then, naturally when the time is up and the disclosure happens according to the timetable, I would be the side looking much the better from it. As such behaving as he did and justifying it in that way is illogical.
I speculate that maybe the reasons he gave may not be entirely the whole story because he would have looked better responsibly disclosing, but its important to note that he doesn't blame poor code, thank you for the correction. And I am speculating for the reasons. Maybe in the future I shouldn't.
Responsible Disclosure has two forms: Coordinated disclosure where the vuln is disclosed to the vendor with a time limit for public disclosure. Full disclosure, where the vuln is disclosed to the public so they can take mitigation steps.
Irresponsible disclosure is selling the vuln to criminal groups or intelligence agencies.
Disagreeing with someone's decisions is not a valid justification for misrepresenting their motives.
I agree with you, it's kinda shitty, but I get where he's coming from. It's incredibly frustrating to want to improve the security of the world, but when developers have too much ego and push back against claims of vulnerabilities in the face of proof, well...every hero either dies or lives long enough to become the villain.
I've experienced it first-hand at a previous job. I found a buffer overflow in some firmware, and engineering just said "Meh, at worst you'll just segfault the device, and the user can just reboot". The fix would have literally just been a two-line buffer length test that throws a 400 Bad Request (It was an embedded web server written in C, with the vuln being in an XML parsing library), but I had to go through the effort of taking that bug and learning ARM assembly and return-oriented programming in order to create a PoC before engineering decided to fix it.
I suppose I should be happy, though, as that learning experience was the cannon that shot me from just being a test engineer into getting into AppSec.
I genuinely liked your opening statement (disagreeing...)
I am sorry to hear you had such a raw experience. Maybe you were dealing with pretty clueless engineers, since most do realize a buffer overflow should be treated exploitable unless proven otherwise. I've had better experience trying to argue the cost of fix -- it being pretty low was incentive enough for engineering to fix it.
That said, I am worried evilsocket may not be taken seriously next time he finds a vulnerability with CVSS 9.9. To some extent I am surprised by his argument on not knowing CVSS scoring rubrik. There may have been language barrier at play as well, leading to some of his sentences coming across as more abrasive than they should have been.
Yes, I can totally empathise with him too. I've behaved in emotional ways in with frustration because of code (but thankfully not in a public way with certain standards of behaviour). Let's hope he can learn from it. It's hard to act professional when acting alone and outside and against the so-called "real professionals".
Ultimately it's about trust. Perhaps these organisations have become too large and uncaring or maybe we have become too impatient and frustrated. I don't think anyone wants to see researchers not responsibly disclosing as well as companies irresponsibly interacting with external researchers who just want to help. It's easy to this as a path from white to black hat.
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.
On RHEL it's installed but it's not enabled by default.
> After some googling I found out that cups-browsed is indeed part of the CUPS system and it is responsible for discovering new printers and automatically adding them to the system. Very interesting, I had no idea Linux just added anything found on a network before the user can even accept or be notified. The more you know!
I don't know, last time i bought a new printer i plugged it into my LAN and my Apple machines automatically showed it to me and I could print to it.
Why blame Linux?
Everyone, please go to your respective data centers, locate your rack and unplug the printer from the server.
Not every Linux machine is a server!
This is kind of a big deal for desktop and even more so for laptop users.
And the percentage of Linux desktops and laptops 1) with printers connected to them 2) directly exposed to the internet, is...?
Is there a recommended (best practice) way to nmap scan your network for vulnerable machines, just to be safe?
From Red Hat's statement: > Red Hat rates these issues with a severity impact of Important. While all versions of RHEL are affected, it is important to note that affected packages are not vulnerable in their default configuration.
Basically, Red Hat machines aren't vulnerable unless "the cups-browsed service has manually been enabled or started."
https://www.redhat.com/en/blog/red-hat-response-openprinting...
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.
>Is there a recommended (best practice) way to nmap scan your network for vulnerable machines, just to be safe?
Perhaps something like this?
Edit: Added [network]/[mask] for completeness.nmap can't really tell the difference between an open or a firewalled UDP port. For this specific vuln you can send it a packet like:
echo "0 3 http://myserver:PORT/printers/foo" | nc -u target 631
And if the target is running CUPS on that port it will reach out to `myserver:PORT` and POST some data. The downside is you need to have a server running that can accept inbound requests to see if it connects back.
You can use --data in nmap to send it easily to the range of hosts (but the server is still needed).
A fair point, although nmap does list results as "closed", "open" or "open/filtered".
Which can be ambiguous if the port is open or firewalled.
However, if the nmap reports that port is "closed," it most likely is:
I'd add that GP specifically requested an nmap command.All that said, you're absolutely correct and if nmap returns something like this:
then further poking could be required, as you suggest.I would point out that cups-browsed isn't really necessary unless you desire to have printers automatically added without any user interaction. Which is poor opsec in any situation.
If we're talking about a corporate environment, adding printers can be automated without cups-browsed, and at home or in the wild (cafes, public wifi, etc.) that's an unacceptable (at least from my perspective) risk and printers (if needed in such an unsecured environment) should be explicitly added by the user, with manual checks to ensure it's the correct device.
As such, rather than checking to see if cups-browsed is running unsecured, simply check to see if it's installed:
Debian and variants:
RedHat/Fedora and variants: And if it is, remove it.Edit: fixed typo.
Surely you don't need sudo for listing with either apt or rpm.
This vulnerability seems to be pretty hard to actually exploit, but for those of you who are running Ubuntu on their desktops, consider enabling a firewall, which is as easy as:
Beats me why this is not the default.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:
You are right of course, but the default policy can be changed using "ufw default allow incoming", making "deny" necessary. You might do it on a laptop/workstation (in a network firewalled from the internet), though it doesn't sound like a great idea to me.
I prefer explicitness when it comes to configuring firewalls. Both for documentation and to guard against defaults changing underneath you.
reload is unnecessary if you make changes via the command line.
Maybe, but it’s good practice to verify that your reload is clean when you are actively working on it.
If by "working on it" you mean "changing configuration files"...
"Good practice" is never an argument btw. "It's good practice" means arguments exist, it is not an argument.
Being pedantic is rarely helpful, especially when the drive to correct people means you rush and neglect to be correct, as you did each time.
There’s nothing magic about configuration files. Any time you are making changes which could impact a system’s ability to restart, you want to test them when you’re ready to fix a problem rather than waiting for the next security patch, power outage, etc. It’s more likely to make mistakes when editing config files by hand but it’s not the only way, and since it’s so very easy to check the argument against doing so is very weak - being confident you haven’t made a mistake is worth the second it takes.
“Good practice” is an argument, but it’s at a different level. Any field has lessons drawn from collective experience, and while those are never perfect and change over time they are a convenient shorthand for things which usually aren’t worth spelling out in detail every time. We say it’s good practice to have backups because most people only need the reminder, not a three page discussion.
You're free to restart anything you want, of course. Reboot the whole machine every time you change anything, that way you'll be sure. I am not stopping you, and in some cases it can be useful to make absolutely certain.
I only pointed out that "ufw reload" is not necessary to make "ufw allow/deny/delete" take effect. Multiple people might not have known that, judging from the upvotes I got. And now I find I have to justify myself. Is that being "pedantic"? Am I the one "rushing"?
I don't see a reason why reload should be "good practice". If ufw or your config is buggy, it is very possible for the rules not to apply at next boot, when iptables is reset. If this is critical, reboot and do a test connection.
There used to be a timeframe (before like 2020) where you could use network printers without any extra software: Open your Document in Firefox, print to postscript, and then netcat that postscript to your network printer port 9100. This is the "AppSocket" protocol.
Unfortunately, Firefox removed that feature, and port 9100 is now clobbered by the Prometheus node exporter. If you accidentally add a AppSocket capable printer to Prometheus it will print out HTTP headers every other minute.
The good times are over, but on the other side, having to print something has gotten quite rare.
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.
Is there a implementation for Linux that isn't cups?
There are a few clients here: https://github.com/topics/ipp
It's not hard to write a client library / CLI, it's just there isn't much interest.
I am slightly confused. If I am using a linux laptop with cups do I need to do anything besides update? Is there a sane way to print from the linux desktop. I unfortunately need to regularly print, and often from public wifi.
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.
This is a misunderstanding of the vulnerability. The problem isn't with the print server. It is with the printer discovery mechanism, cups-browsed. That is the service that listens on the entire network, because it's designed so that LAN printers can advertise themselves to your system.
In that case one can disable it until it is patched assuming there isn't a udev rule that re-enables it. I stay clear of systemd these days so I don't know.
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:
Thank you. I was also able to check that 631 is blocked by searching for it in output of sudo ufw show raw.
I though this was going to be NetworkManager the way they were hyping it up.
I checked 5 linux desktop/laptops here and none of them had cups-browsed or port 631 exposed. They are all able to print to a network printer. The vulnerability is real though perhaps the impact is exaggerated. Distros that tend towards installing a minimal selection of packages and services are less exposed.
Maybe the report was overblown, but I found it amusing that CUPS related facilities is shipped and activated by default in a lot of Linux distros (including Gnome Fedora in my case). I've never printed anything on this computer and yet there is this `cupsd` process running as root and listening TCP port 631 on local interface.
OK, sure, the program itself maybe safe (enough to run with root while listening a local port that everybody uses this computer can access), but is it really THAT evil if you don't run it 24/7 and instead only enable it when the user is actively using it?
Do networked printers themselves run CUPS? E.g. a Brother or HP laserjet plugged into a LAN.
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.
Queue everyone going to Shodan and investigating how many systems have port 631 on UDP open..
my grandparents who are still printing things like its the 90s might be at risk, if they have installed CUPS that is
has the president been briefed yet?
we should fix this, CUPS is used in a bunch of consumer hardware
it's not a complete disaster like it was implied to be though
I don't believe this warranted all the fearmongering even if the intention was to get more attention to it and a faster resolution process, it's not far from cry wolf. Initial CVE scores are very arbitrary. CUPS is a well-known liability when exposed to unsafe networks. CVSS scores seem far from perfect. The WebP zero-day, a zero-click vulnerability that was being exploited in the wild and affecting nearly every user device made in the past decade, most of which will never be properly patched from it, received an initial 10.0, and decreased to a meager 8.8 (CVSS:3.1, and would be higher using 4.0).
Why are distros allowing CUPS to listen on all interfaces, then?
The problem isn't CUPS itself, which is not made to listen on all interfaces by default. The problem is the printer discovery service, cups-browsed, which listens for any printer on the LAN (or any attacker anywhere) that advertises itself to it and automatically registers that printer in your system.
Whether it's a good idea to have a service like this is highly debatable, but if it is added, it has to listen to all requests from anywhere (and the firewall port for it has to be open), otherwise it's entirely useless.
many distros change this to unix sockets or 127.0.0.1
A basic firewall configuration could easily prevent this even if you are running the vulnerable version
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.
This is nowhere near as severe as the Heartbleed bug.
It is bad if you print from a Linux laptop that uses WiFi isn’t it?
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.
Plenty of laptops have a built in modem and this is becoming more ckmmoj every day. Those connect directly to the internet.
NAT only makes a difference if you use. IPv4 only. If you have dual stack, then your host is on the public internet.
The attacker can be on the LAN though.
Sure but security isn’t about being 100% protected which is impossible, but lowering your attack foot print. Unless you have a ton of people hooking to your LAN regularly then this still greatly lowers you chances of getting hit with this particular security flaw by people on the WAN
A useful target might be university networks, although IIRC our university printers weren’t available for discovery. Instead we would send our documents to a special email that would forward it to a local print server so we could get charged for it.
I remember there was some like viral marketing thing some company did a while back where they had a website where they had a webcam pointed at a printer, and anything printed would go on a conveyer belt and fall into a literal dumpster fire. Users could submit stuff on their website and see it printed and burned live.
...anyways, maybe they were vulnerable to this attack at the time?
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.
Everybody saying this is nothing burger is absolutely wrong. This is not overhyped. A lot of comments like, well my distro doesn't do this, and well yeah nobody uses printers anymore. A print server is design to be exposed. Office networks will use one and they have important data. You would think there would be some kind of hardening.
Honestly, this looks intentional.
Is printing obsolete yet?
I suppose the real question now is: did the author give it a 9.9 out of ignorance or malice/ego?
RedHat did, as per the article
I'm gonna give this a 10/10 meh. Not up to all the hype that was created around it.
[flagged]
This is a nothing-burger...
So just to make sure I understand correctly, this is a nothingburger, right? No important server has a printer attached. Any basic firewall would block this traffic.
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.
botnetting is about exploiting unimportant desktops, to create very important servers.
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.
But why would such desktops be exposed to the public internet directly?
Likely no good reason. But he seemed to have identified many many systems that were, inexplicably, exposing port 631 to the internet. There is some reason people are doing it and, given the number of target systems, it must be some sort of default configuration.
The likely target that emerged in my mind reading this is mom and pop point of sale systems.
The operators of such systems are completely oblivious to such risks, and the underpaid PoS software support team following a script to restart CUPS probably are as well.
The 9.9 issue is the foomatic-rip vulnerability; not cups-browsed listening on 0.0.0.0. See here:
> 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.
I believe you'd still need cups-browsed installed, enabled & configured to accept remote printer broadcasts, _and_ have foomatic installed locally in order to get hit by this.
Modern version of cups will basically only talk to "driverless" IPP Everywhere printers, which all understand a common set of raster formats and hence have no need for printer-model specific software like foomatic-rip to be installed. They do this via mDNS, which means you don't need cups-browsed to be installed either.
I see. This sounds like a problem for people using public wifi...
Maybe, maybe not. If I understand correctly, you still need to print something to the printer to achieve RCE via foomatic-rip.
You do, until someone finds a way to exploit the other buffer overflows. But also, this attack is persistent: you get infected without any interaction at the coffee shop, and two years later when you print something at home on your well secured network: BAM!
Uh, how? Unless somehow it stays around even though you've left the network (which I didn't think happens, but I could be wrong), this lasts just as long as the mDNS attacking server is on the network?
This to me feels like the author missed why the system was set up the way it was, and therefore doesn't present useful solutions.
Per the article, the attack works like this:
The attacker sends a malicious UDP datagram to the target computer, telling it is a printer available at ATTACKER_CONTROLLED_URI.
The vulnerable computer receives this packet and proceeds to download the "printer information" (attacker-controlled printer scripts) from ATTACKER_CONTROLLED_URI and store it in a PPD file as an available printer, potentially overwriting an existing printer.
There is no user intervention needed, nor any notifications to the user, up to this point. The PPD files are persistent: they will stick around ~forever on your system until some other printer replaces them, or you manually delete them.
Whenever you want to print, CUPS looks for all the PPD files currently on the system and provides print options based on them. If you choose to print using the malicious printer (which might look like one of your known printers), the information in the attacker-controlled PPD file will be used by CUPS, including Foomatic scripts that can run more or less arbitrary code with root privileges.
The biggest issue with all of this is that Linux doesn't distinguish between trusted LANs, where arbitrary printers connecting to you is actually a pretty nice feature; and public untrusted LANs, where this is DEFINITELY not a good idea. Also, the fact that your printer infra can run arbitrary code as root, code supplied by the remote printer itself, is another level of crazy.
> Linux doesn't distinguish between trusted LANs [...] and public untrusted LANs
Gotta be the annoying and point out here that Linux is a kernel. Fedora Workstation, for instance, has firewalld installed & enabled by default, which does apply different policies to different network zones. Hook a default system up to a hostile coffee shop, and TCP/UDP ports <= 1024 are blocked by the default FedoraWorkstation zone. NetworkManager connections have a 'zone' property that the user can change to 'home', 'trusted', etc.
> Also, the fact that your printer infra can run arbitrary code as root, code supplied by the remote printer itself, is another level of crazy
Only, it seems, if non-default legacy printer drivers (foomatic) and discovery services (cups-browsed) are present. And doesn't cups run backends as an unprivileged 'lp' user? And confined by MAC (again, in the Red Hat world, SELinux confines it to the cupsd_t domain). So not _that_ crazy.
Disabling foomatic seems hard since the PPD can be distributed by the attacker and foomatic-rip is part of the cups-filter package. But yes, lp user + SELinux should be enough to make this not a 9.9.
I actaully didn't realise that foomatic is part of cups-filters now?! On the other hand - it's only 'activated' by cups-browsed, if I understand correctly, at least by the currently disclosed set of vulnerabilities... let's hope an attacker can't craft a printer that will trick cups itself into configuring a dodgy print destination...
Github has given it a 4.4 score: https://github.com/OpenPrinting/cups/security/advisories/GHS...
That's unrelated to these findings.