Attacking UNIX Systems via CUPS
evilsocket.net
evilsocket.net
> 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.
> 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.
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.
≻ 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
That's a nice touch, and it'd be cool if Linux distros added 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.
--
Apple CUPS is a distinct distribution of 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'.)
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.
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.
> 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.
> 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.
I wonder, has the guy tried reproducing the exploit on RHEL/Fedora or some other SELinux-protected system? Because this looks like the kind of issue that SELinux would protect you from:
1. cups likely does not have permissions to go and write executable binary files around
2. cups likely does not have permissions to go and exec binaries without the appropriate labels
I still think that maybe you could steal printing document, but i haven't tried. Anyway, i see there's plenty of CUPS-related selinux work documented via manpages. Example: https://www.systutorials.com/docs/linux/man/8-cupsd_selinux/
Also, why do you think that seeking recognition for your efforts a bad thing?
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.
> 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.
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.
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.
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.
It was a bit tough at first but writing your first SELinux profile is a fantastic way to make it approachable. YMMV, of course.
You can write and understand llms but not selinux policies..
You are right, the crowd has spoken. Thank you for the education hn.
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?
There are tons of 10s and for, what are IMO, really silly things.
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.
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.
The author may have some attitude problem, but this is a legit Big Deal vulnerability.
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
Hyped it up to be some massive thing but it turned out to be a massive nothingbuger for me at least
I can think of another reason they got patronised.
>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
I do not understand how the mDNS entry point works.
Sent from my Ubuntu laptop.
[edit: I was wrong, it listens on 0.0.0.0 for UDP. I was only checking TCP. ]
I'm not sure why it deviates from Debian and Ubuntu which its based on though
But it looks like cups-browsed is only needed on the Internet; locally you only need mDNS.
A modern setup doesn't need it and doesn't use it.
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?
EDIT: Here's a description of the protocol in question: https://opensource.apple.com/source/cups/cups-327/cups/doc/h...
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 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.
There is no detail in the article about the other.
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.
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.
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.)
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.
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.
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.
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.
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.
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.
Fortunately, in this case, cups-browsed uses port 631/udp :)
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.
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.
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...
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 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.
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.
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.
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.
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.
Setting up an old RPi with CUPS helped a bit. For a while. Now I'm back to having to re-add printers to my mac workstation every time I want to print.
pdf2ps <doc> - | nc <printer> 9001
Didn't do Unicode unfortunately, and monospace only, and no bold and stuff like that.
But still the best printer I've ever owned.
Saying it affects all "Linux" systems is just wild.
Imagine even having that thing on your system to begin with.
Do people have printers that move around all the time?
Also, firewalls on desktops and laptops for the win, yet again.
I suspect it's not the printers that are moving, but the laptops.
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 send something from outside of my house to my house, I’ve done using a vpn.
> 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.
Well it is the Common UNIX printing system...
If it was the Not-oft-used Printing System I could understand.
I've talked about alternatives in another reply, they do not offer the same flexibility as CUPS however.
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?
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.
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.
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.
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.
[1]: https://www.usenix.org/system/files/login/articles/login_aug...
Still, kudos to the author who found it, it's going to definitely be a career boost with all the world is ending headlines.
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.
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.
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?
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".
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.
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.
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.
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.
Irresponsible disclosure is selling the vuln to criminal groups or intelligence agencies.
https://x.com/evilsocket/status/1839433162168181051
Anyway, I don't like his tone and he's overreacting imo.
It is.
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...
Perhaps something like this?
nmap -sU -p 631 -P0 [network]/[mask]
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.
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
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
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:
'sudo apt list --installed | grep cups-browsed'
'sudo rpm -a -q | grep cups-browsed'
Edit: fixed typo.
Under the hood its basically running an nmap scan and spitting out a PDF report.
This is kind of a big deal for desktop and even more so for laptop users.
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?
sudo ufw enable
> sudo ufw deny 631
> sudo ufw reload"Good practice" is never an argument btw. "It's good practice" means arguments exist, it is not an argument.
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.
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.
deny 631
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?
sudo ufw enableOn 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.
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.
It's not hard to write a client library / CLI, it's just there isn't much interest.
Unfortunately there is a torrent of bullshit artists claiming bullshit vulnerabilities in software. Much of it is pure nonsense such as hallucinating AI's describing imaginary bugs in imaginary code and much of what little is real is extremely overhyped-- stuff like "DOS attack where the victim has to keep clicking on the attacker's button" or, more charitably "DOS attack which is strictly less impactful than a ping flood".
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.
has the president been briefed yet?
it's not a complete disaster like it was implied to be though
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.
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.
NAT only makes a difference if you use. IPv4 only. If you have dual stack, then your host is on the public internet.
...anyways, maybe they were vulnerable to this attack at the time?
Honestly, this looks intentional.
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.
> "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."> 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.
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.
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.
The original article seems to spend more time being vague about the actual issue (it's notable that the PoC video makes it really hard to see the steps), and if this vagueness was in the original security reports, I'm not surprised it wasn't well received (c.f. the vague bug reports curl gets).
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.
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.
2. Probably your firewall, if configured, will block it. But that doesn't stop LAN requests, which can be a big deal for huge networks.