Tiberium
9 months ago
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.
crote
9 months ago
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.
sam_lowry_
9 months ago
CUPS 3 goes the other way, relying solely on IPP for discovery and autoconfiguration.
yrro
9 months ago
> 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.
seanhunter
9 months ago
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?
rini17
9 months ago
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.
Tiberium
9 months ago
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.
tsimionescu
9 months ago
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.
nickphx
9 months ago
Ehh most public wifi spots segment clients... You will be unable to send traffic to neighbors...
mschuster91
9 months ago
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.
forgotpwd16
9 months ago
Reminds me when used to redirect or/and replace images on sites in cafés with zANTI.
tsimionescu
9 months ago
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.
nullindividual
9 months ago
That's nearly as many as Code Red and roughly 100K more than SQL Slammer.
chupasaurus
9 months ago
Add every macOS-running device to the picture (who disables cupsd?)...
sitharus
9 months ago
My mac right now running Sonoma 14.6.1, with no system modifications or MDM:
≻ ps aux | grep -i cups
xxxxx 31407 0.0 0.0 410741456 1600 s000 S+ 3:18pm 0:00.01 grep --color=auto -i cups
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.pxc
9 months ago
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.
naming_the_user
9 months ago
Same here. Also, using netstat for the PID you can see that it's only listening on localhost ipv4/ipv6.
cowsandmilk
9 months ago
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.
tsimionescu
9 months ago
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.
user
9 months ago
pxc
9 months ago
CUPS is also part of iOS and iPadOS.
formerly_proven
9 months ago
If those ship cups, why do they require special AirPrint-compatible printers?
pxc
9 months ago
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.
--
seba_dos1
9 months ago
CUPS predates iOS by a decade and wasn't developed by Apple.
Apple CUPS is a distinct distribution of CUPS.
pxc
9 months ago
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'.)
nullindividual
9 months ago
macOS has a firewall on by default.
tsimionescu
9 months ago
That doesn't help if the goal is to allow printers to register automatically to your system.
cjbprime
9 months ago
Are you sure? E.g. the blog post mentions a one-byte read overflow, which is unlikely to be directly exploitable.
rini17
9 months ago
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.
user
9 months ago
ezekg
9 months ago
> 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.
H8crilA
9 months ago
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.
tga_d
9 months ago
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.
voytec
9 months ago
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
Arch-TK
9 months ago
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.
dfc
9 months ago
But it seems like User Interaction is required.
tsimionescu
9 months ago
Printing something at some point arbitrarily later on the system is almost certainly not classed as User Interaction in this sense.
Tiberium
9 months ago
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.
Fnoord
9 months ago
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.
tsimionescu
9 months ago
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.
BenjiWiebe
9 months ago
How do they get around the built-in firewall that's been standard on home routers for the past 15 years?
dwattttt
9 months ago
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.
tsimionescu
9 months ago
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.
gmuslera
9 months ago
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.
a96
9 months ago
Or, there are a whole lot of sites running honeypots. But it's still probably a very large number.
pxc
9 months ago
The I in IPP stands for 'Internet'. I guess some people really mean it.
that_guy_iain
9 months ago
> 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.
znpy
9 months ago
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).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/
Fnoord
9 months ago
Evilsocket is a known hacker. They made for example Bettercap (Pwnagotchi), Opensnitch, and a myriad of other tools. They don't need fame.
jsiepkes
9 months ago
People who already have some level of fame often feel pressure to keep meeting "expectations".
mort96
9 months ago
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?
shrubble
9 months ago
The first thing many do in the real world, after installing RHEL or the free derivatives is ... turn off SELinux.
worthless-trash
9 months ago
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.
iforgotpassword
9 months ago
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.
TheNewsIsHere
9 months ago
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.
ungamedplayer
9 months ago
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.
znpy
9 months ago
> 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?
yrro
9 months ago
If you want to get fired, sure!
shrubble
9 months ago
I know of 2 large telecoms where this happens! However they have large firewalls in front of the servers.
anthk
9 months ago
Cups needs permissions for Foomatic and some printing filters.
user
9 months ago
dumpsterdiver
9 months ago
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?
znpy
9 months ago
> 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.
outworlder
9 months ago
> 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.
dumpsterdiver
9 months ago
> 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.
user
9 months ago
Arch-TK
9 months ago
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
worthless-trash
9 months ago
Heartbleed was a different CVSS version.