> 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.
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.
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.
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).
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?
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
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!
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.
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.
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
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.
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 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.
> 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.
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)
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.
Readit News
> 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.
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.
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.
> Impact wise I wouldn’t classify it as a 9.9, but then again, what the hell do I know?
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.
The author may have some attitude problem, but this is a legit Big Deal vulnerability.
> 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
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.
There are tons of 10s and for, what are IMO, really silly things.
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/
Deleted Comment
Also, why do you think that seeking recognition for your efforts a bad thing?
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
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!
[edit: I was wrong, it listens on 0.0.0.0 for UDP. I was only checking TCP. ]
I certainly expect that a Linux laptop shouldn’t be highly vulnerable to every other device on, say, an æroport’s WiFi.
The OS you have in mind is called OpenBSD, which has had two remote holes in the default installation in about 3 decades; and if you don't need to run Linux-only applications, it actually is a pretty decent desktop.
I don't blame Linux distributions however - both Windows and macOS are way worse. We've been living through a crisis of complexity, everyone is keen to call out Electron apps but we keep on installing and using them. As long as we accept this complexity, things will keep getting worse.
Hyped it up to be some massive thing but it turned out to be a massive nothingbuger for me at least
>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
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.
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.
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.
Deleted Comment
Saying that all systems running cups can be hacked is a misrepresentation of the scale of the issue.
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.
0: https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-stands-f...
I suppose CUPS was introduced in 1999 so it probably made sense then. But why is it still a thing today?
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)
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.