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.
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?
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.
≻ 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
> 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.
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.
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.
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:
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/
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.
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?
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.
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!
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.
[edit: I was wrong, it listens on 0.0.0.0 for UDP. I was only checking TCP. ]
But it looks like cups-browsed is only needed on the Internet; locally you only need mDNS.
I'm not sure why it deviates from Debian and Ubuntu which its based on though
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...
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.
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.
Fortunately, in this case, cups-browsed uses port 631/udp :)
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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.
> 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?
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.
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.
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.
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.
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.
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.
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?
https://x.com/evilsocket/status/1839433162168181051
Anyway, I don't like his tone and he's overreacting imo.
It is.
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.
Irresponsible disclosure is selling the vuln to criminal groups or intelligence agencies.
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.
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?
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.
sudo ufw enableUnfortunately, 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.
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.