I also cannot believe that this is the 9.9 rated CVE. For comparison, heartbleed was a 7.5. I was awaiting a Total Linux Meltdown at best and a collapse of the world economy at worst with the amount of hyping up and fearmongering that the author did on social media.
Yeah tbh it's not as bad as he claimed. I doubt this is actually rated 9.9:
>A remote unauthenticated attacker can silently replace existing printers’ (or install new ones) IPP urls with a malicious one, resulting in arbitrary command execution (on the computer) when a print job is started (from that computer).
>WAN / public internet: a remote attacker sends an UDP packet to port 631. No authentication whatsoever.
>LAN: a local attacker can spoof zeroconf / mDNS / DNS-SD advertisements (we will talk more about this in the next writeup ) and achieve the same code path leading to RCE.
Still, sucks for linux desktop users. Looks like any random device on your wifi/vpn can screw you over
Keep in mind that you still need send a print job to the fake printer to trigger the exploit. If you send the job to your real printer, nothing happens.
It appears that the vulnerable service in question listens on 0.0.0.0 which is concerning, it means attacks from the LAN are vulnerable by default and you have to explicitly block port 631 if the server is exposed to internet. Granted, requires user to print something to trigger which, I mean, I don't think I've printed anything from Linux in my life, but he does claim getting callbacks from 100's of thousands of linux machines which is believable.
I guess the important question is whether or not these things are blocked by default or require user intervention to disable cups? Sure, many of us block all ports by default and either route everything behind a reverse proxy or punch very specific holes in the firewall that we know are there and can monitor, but someone firing up an ubuntu distribution for their first foray into linux is probably not thinking that way.
The people who are crashing their 600HP Linux systems are, unfortunately, not the ones who are reading CVE listings in their spare time. Canonical and other distros are probably going to have to patch that default setting.
There are a lot of comments on here that assume Linux is only for servers. But just recently there was a post on HN indicating Linux will likely hit 5% desktop share for the first time this year. That's a lot of people on Linux - and a far higher percentage of people using Linux on the desktop will not know anything about this. Sane defaults should not be a luxury. Of course people should know to wear their seatbelts, but seatbelt alarms are still a very good thing.
And this is why Microsoft force pushes updates. I think when Linux desktops become really popular there is quite a worry if the users simply do not update them regularly enough. Or if they are not secured in most ways by default.
Modern cups discovered printers via mDNS and does indeed automatically create temporary destinations for them. This only works with "IPP Everywhere" printers which are 'driverless', i.e., the risk of doing this is limited since there's no printer model-specific software that needs to be run on the local machine to print to a remote printer, as opposed to the legacy protocol implemented (apparently unsafely!) by cups-browsed.
On my Ubuntu 22.04 machine, cupsd itself is only listening on localhost, but cups-browsed (which is what has the vulnerability here) is listening on 0.0.0.0
I believe it's implementing DNS-SD for network printer auto-discovery. I'm not terribly familiar with DNS-SD, but given that normal DNS is UDP based it would be unsurprising for DNS-SD to also use UDP.
The purpose of cups-browsed is to listen on a UDP port which allows it to receive broadcasts from legacy cups servers on the local network, whereupon it will talk to cups and configure a local print queue for the printers on the discovered server.
A modern setup doesn't need it and doesn't use it.
I am very unfamiliar with the protocol, but my impression from a little reading is that the sharing computer broadcasts and the receiver listens. This appears to be for some CUPS specific browsing/discovery protocol rather than mDNS/DNS-SD (cups-browsed supports adding printers discovered that way but depends on avahi to handle the mDNS part).
No, per the article, cups-browsed is used so that a printer can register itself to your system. The printer is the one that initiates a connection to tell your system that it is available at some URL.
Assuming that most routers are silently compromised, with their command-and-control operators just waiting for an exploit like this one, is almost par for the course these days!
The problem: you're thinking in terms of home/small business networks.
The rest of us are thinking in terms of larger networks (in my case with hundreds of subnets and tens of thousands of nodes) where "631 is blocked at the firewall" isn't of much relief. The firewall is merely one, rather easy to get past, barrier. We're also concerned with east/west traffic.
For sure, and sending hug-ops to teams like yours that have to deploy & enforce mass patches! But I'm also thinking of environments that don't even have the benefit of a team like yours. https://issuetracker.google.com/issues/172222838?pli=1 is (or seems to be?) a saving grace, without which every school using Chromebooks could see worms propagating rapidly if even one student connected to a compromised router at home.
Would you also not block this at the firewall on individual nodes: if you block incoming incoming UDP on port 631 that would at least eliminate one of the two entry points, right?
There is no detail in the article about the other.
The port has to be open on the node for the functionality to work - the whole point is that printers on the same LAN can auto-register. If you don't want that, disabling cups-browsed is much safer than just relying on the firewall. If you do want that, you can't firewall the port at all.
It's because of the frankly idiotic idea of persistent print queues. If you want to have this artifact that survives a user session, then the print subsystem needs super-user abilities.
ChromeOS does away with the whole idea. There are no persistent printer queues or jobs. Artifacts of the printing subsystem have lifetime tied to the user session.
It's a spooler for a printing system that supports concurrent job submission, potentially among multiple users. It's going to have to achieve serialization some kind of way.
As long as that user can talk to the printers' device nodes (and/or the network), it needn't so far as I know.
The original "system daemon vs. user program" dichotomy offers a much broader range of interpretations than this, though, and it was more the implication of "this can and should be an evanescent program invoked by individual users, implicitly persisting little or no state between invocations" to which I sought to object.
(That said, I take another nearby commenter's point regarding the need, and existence, of a more evanescent and safer option on systems that will never see more printing than one user does two or three times a year.)
They don't. cups-browsed is a legacy component that isn't needed on ordinary systems, which outsource printer discovery to an mDNS service such as avahi.
I believe these vulnerabilities only allow RCE as the 'lp' user (which is able to access parallel ports and USB devices that identify themselves as printers). In addition the process will be confined by MAC policies (e.g., on Fedora/Red Hat I think they're confined by cupsd_t).
I have never, in the entire history of my usage of desktop systems, wanted my system to spool out a print job on behalf of a non-current user. Nor have I wanted my system to continue servicing my print queue after I log out. To the contrary: it’s incredibly annoying when the queue glitches out and then my print jobs show up in the printer tray after I’ve left.
On multi-user systems (accessed simultaneously by multiple interactive accounts), sure, I’ve once worked in a lab where multiplexing a printer would make sense. Make this a non-default option, please. And have a printer multiplexing daemon, not an entire shared monstrosity like CUPS.
On terminal-server style systems, the print system should be per user, because the printers are per user. I don’t want to print to a printer wherever the terminal server lives — I want to print to the printer near me.
I once ran an actual print server for a couple years. It did accounting, correctly, by wiring CUPS to a little program I wrote that actually spoke PJL correctly. CUPS, of course, can’t actually do this.
On Ubuntu, both.
A system daemon with interesting interactions with avahi-daemon and colord, and a somewhat sandboxed user program, just so Chrome is not overly inconvenienced by its snap sandboxing.
But wait, there is more: The login & lock screen also runs the whole glory of GNOME.. to query printer settings. So you can have those sweet, sweet "new printer" notifications overlaid while inputting your password. Or whatever else "your" printer needs to add there.
The prevalence of attitudes like this in the Linux community is why the year of the Linux desktop will never come.
Imagine if your brand new refrigerator, by default, would leak toxic refrigerant into your kitchen unless you adjusted a valve just so.
This fact is not called out prominently in the manual, but if you read the fine print in the manufacturer's assembly instructions and have a working knowledge of how a refrigerator operates, you can maybe infer that this valve must be adjusted after purchase to prevent leakage.
You go on their support forum to try to figure out why your brand new refrigerator is emitting toxic refrigerant, and you're essentially called an idiot and told you don't have "basic refrigerator hygiene."
People don't want to become refrigerator mechanics. They want cold food.
Because you don't need a firewall on a sensibly configured desktop computer.
If you have daemons that listen to incoming connections, you only want to run them if they are sane and secure.
A firewall makes sense when you don't trust the daemons in your lair, eh, network, and you don't have the possibility to replace insecure stuff with secure stuff. But a firewall must be maintained by experts.
For a single computer it is much easier: just make sure it is secure and don't add an extra layer of complexity to it.
That attitude was popular in the 90s but any definition of “sensibly configured” in this century involves a firewall.
The reason is that even experts make mistakes, get busy, or rely on assumptions which turn out to be incorrect. For example, you thought your service which uses strong authentication and encryption was safe to expose – and then Heartbleed or RegreSSHion happened. If you restricted ingress, you slept calmly. If you had it open, you had an emergency rush to patch and look for signs of compromise.
It sounds like in this case “exposing CUPS to the Internet” means “running a Linux desktop on the Internet” which while not something I would do doesn’t seem crazy. I would hope that a default Debian desktop installation would be secure enough to set up without a firewall.
I certainly expect that a Linux laptop shouldn’t be highly vulnerable to every other device on, say, an æroport’s WiFi.
> I would hope that a default [OS] desktop installation would be secure enough to set up without a firewall.
The OS you have in mind is called OpenBSD, which has had two remote holes in the default installation in about 3 decades; and if you don't need to run Linux-only applications, it actually is a pretty decent desktop.
I don't blame Linux distributions however - both Windows and macOS are way worse. We've been living through a crisis of complexity, everyone is keen to call out Electron apps but we keep on installing and using them. As long as we accept this complexity, things will keep getting worse.
Possibly because the devs reduced the numbers he says: "because the devs just can't accept that their code is crap - responsible disclosure: no more"
Always kind of worrying to see vulnerability researchers justifying bad behaviour because they find a vulnerability in code. Maybe it was because his pride was hurt that he threw away any ethical behaviour?
> vulnerability researchers justifying bad behaviour because they find a vulnerability in code
This is an extremely bad faith take that makes me irrationally angry to read.
He's not using bad code as a reason to engage in bad behavior, he's using bad responses to responsible disclosure. Read the section under "Personal Considerations". It only took him two days to find the problem, but 22 days to get developers to admit there's a vulnerability, even when shown PoCs.
Imagine finding a vulnerability, responsibly disclosing it, being told "meh, not an issue", responding with a PoC showing full code execution, and still being told "meh, not an issue".
> Imagine finding a vulnerability, responsibly disclosing it, being told "meh, not an issue", responding with a PoC showing full code execution, and still being told "meh, not an issue".
I would still want to be responsible. I shouldn't get to choose to be irresponsible when I have a bad experience. Then, naturally when the time is up and the disclosure happens according to the timetable, I would be the side looking much the better from it. As such behaving as he did and justifying it in that way is illogical.
I speculate that maybe the reasons he gave may not be entirely the whole story because he would have looked better responsibly disclosing, but its important to note that he doesn't blame poor code, thank you for the correction. And I am speculating for the reasons. Maybe in the future I shouldn't.
Disagreeing with someone's decisions is not a valid justification for misrepresenting their motives.
I agree with you, it's kinda shitty, but I get where he's coming from. It's incredibly frustrating to want to improve the security of the world, but when developers have too much ego and push back against claims of vulnerabilities in the face of proof, well...every hero either dies or lives long enough to become the villain.
I've experienced it first-hand at a previous job. I found a buffer overflow in some firmware, and engineering just said "Meh, at worst you'll just segfault the device, and the user can just reboot". The fix would have literally just been a two-line buffer length test that throws a 400 Bad Request (It was an embedded web server written in C, with the vuln being in an XML parsing library), but I had to go through the effort of taking that bug and learning ARM assembly and return-oriented programming in order to create a PoC before engineering decided to fix it.
I suppose I should be happy, though, as that learning experience was the cannon that shot me from just being a test engineer into getting into AppSec.
Yes, I can totally empathise with him too. I've behaved in emotional ways in with frustration because of code (but thankfully not in a public way with certain standards of behaviour). Let's hope he can learn from it. It's hard to act professional when acting alone and outside and against the so-called "real professionals".
Ultimately it's about trust. Perhaps these organisations have become too large and uncaring or maybe we have become too impatient and frustrated. I don't think anyone wants to see researchers not responsibly disclosing as well as companies irresponsibly interacting with external researchers who just want to help. It's easy to this as a path from white to black hat.
I genuinely liked your opening statement (disagreeing...)
I am sorry to hear you had such a raw experience. Maybe you were dealing with pretty clueless engineers, since most do realize a buffer overflow should be treated exploitable unless proven otherwise. I've had better experience trying to argue the cost of fix -- it being pretty low was incentive enough for engineering to fix it.
That said, I am worried evilsocket may not be taken seriously next time he finds a vulnerability with CVSS 9.9. To some extent I am surprised by his argument on not knowing CVSS scoring rubrik. There may have been language barrier at play as well, leading to some of his sentences coming across as more abrasive than they should have been.
Responsible Disclosure has two forms: Coordinated disclosure where the vuln is disclosed to the vendor with a time limit for public disclosure. Full disclosure, where the vuln is disclosed to the public so they can take mitigation steps.
Irresponsible disclosure is selling the vuln to criminal groups or intelligence agencies.
Is that an exact quote? He says that he disclosed it now because there was a leak and "all vendors that bothered participating agreed on today at 20:00 UTC".
Maybe less exciting, but still terrible for almost anyone running a Linux desktop/laptop, especially those that expect it's safer than a Windows desktop. And it's a really bad look both for the developers of CUPS, and for most Linux distros, including RHEL, that just enabled this printer discovery backdoor by default without any mitigations in place.
Every time I need to print something on MacOS I am reminded of how much I hate printers and any printer related software. I've been messing around with computers for 40 years now and goddamnit, every decade printers become more of a pain in the neck.
I wrote printer code for 10+ years. I appreciate how hard the technical problems are but vendors make it so much worse. I loathe printers. Printers peaked with the LaserJet III.
IIRC the Laserjet 4 had a much better warm-up time (and lower power consumption) by switching to a thin ceramic heating element rather than heating half the printer. But yeah anything after that is downhill.
do you mind lightly summarizing what technical problems make it more difficult? I'm assuming there are all sorts of things web-devs never even think about from that world.
Poor status, often a 1 line LCD says "processing..." and hangs infinitely.
Different handling of duplex, monitoring ink levels, file formats (PS? EPS? PNG? PCL? Which versions? Etc).
Issues with ink that expire by date, reduced functionality with 3rd party inks, not being able to print black even when only yellow is out of ink.
Different postscript versions and the nature of a language where CPU and memory use is unbounded means you get a nightmare of which files can print to which printers.
Most of our printer nightmares, at least the software issues, ended when we handled postscript -> PCL (a raster based format) on the server side.
Agreed, I ran several busy printers for a large department. The ljet IIIs were work houses and ran nearly forever if you used the recommended part replacement schedule.
We had a ljet III that outlasted ljet 4, ljet 5, and ljet 4000. Ljet 3 was the last with the HP print engine, afterwards they used Canon print engines.
The network interface was brittle, even a nmap would hang the printer. So we firewalled it off and used CUPS to handle postscript -> PCL. Sending only PCL to the printer (postscript memory and CPU is unbounded) made them faster and MUCH more reliable.
I feel like printers are far better now than they were 10 years ago. At least on MacOS and iOS, I have no problems finding a printer and printing. 10 years ago it was a pain, but now - smooth sailing for me. Heck, no driver installs either!
Yeah something like 10-15 years ago I thought for just the simple action of printing a file, it was way easier in Ubuntu than Windows, simply because they included a lot of drivers in the distro by default, while in Windows land I still had to visit the printer manufacturer's website for drivers -- or use the included CD! I try to avoid needing to do anything more complex than that. (Scanning I've always done with a USB stick plugged directly into the printer.) Things kind of got worse again in recent years with the removal of the standalone GUI for administration in favor of a web interface, and various ongoing modularization efforts, in theory cups3 will work even better and only support IPP/AirPrint: https://openprinting.github.io/current/#the-new-architecture...
Well, apart from printers added throug Bonjour constantly going missing and have to be re-added regularly, and (HP) printer drivers suddenly no longer working and being flagged as malware after OS upgrades.
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.
Funny how the whole FSF movement started in no small part because Stallman was irritated with the low quality of printer drivers... and how that movement for some (?) reason failed, in 40 years, to noticeably improve the quality of printer-related software.
Fair, but do people print away from home very often? I’ve never printed anything outside of home since high school, but maybe I’m an outlier.
Maybe a better question, would intentionally adding a printer at home and a printer at the office be that large a barrier?
Maybe we wouldn't even need to drop auto discovery. Maybe it could work more like Bluetooth and only broadcast or accept connections while it was actively searching.
If you mean use someone else’s printer, I do it occasionally. Usually TTRPG character sheets. I am so happy AirPrint is common now. Makes my life easier.
If you mean send something from outside of my house to my house, I’ve done using a vpn.
> In part II of this series (date TBD since there’s another disclosure in process), we’ll see how to use these new bettercap modules (not yet released) to attack Apple macOS.
I can't imagine it on a normal server expected to serve public internet requests. The way you phrased that though makes me wonder for desktop use, is there a non-cups alternative to printing on linux these days that's gone under my radar? (Please don't say there's a systemd-print...) If nothing else, probably another overdue candidate for the energetic rewrite-it-in-Rust people.
> 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.
> I personally haven't printed anything for a long time, so I might've been biased in my reply.
Huh. I print less and less since college, but it honestly hadn't occurred to me that you might be a desktop Linux user who just doesn't print anything.
> There at printers that let you send a pdf directly to their ip address, ones that take in usbs, etc...
> As another thought, why does it come by default on most distros given its history?
I assume because people who do much printing definitely want to print in a 'normal', way, directly from applications. Isn't CUPS the only game in town there? That adds up to a lot of inertia. CUPS is mature and featureful and has been around for a long time, plus is integrated with the rest of the stack and all the applications, and it has no direct competitors on those platforms, as far as I'm aware.
Maybe Red Hat would be interested in producing a CUPS replacement, but they may also feel like for Fedora users and desktop users of Red Hat, SELinux and occasional emergency patches is good enough for what is ultimately not their core audience, as well as a hell of a lot cheaper and more politically feasible than a from-scratch rewrite. Idk who else would likely be interested in funding such a project.
So just to make sure I understand correctly, this is a nothingburger, right? No important server has a printer attached. Any basic firewall would block this traffic.
I don't know if I would say it's a nothing burger, but i don't see how it affects important servers. It might impact a number of linux desktops and, if they are linked to important servers, provide a backdoor access into important services.
Being able to run arbitrary code in a root account with no authentication would seem to be a pretty important security breach, although I don't think it's quite the level of danger it was built up to be.
Likely no good reason. But he seemed to have identified many many systems that were, inexplicably, exposing port 631 to the internet. There is some reason people are doing it and, given the number of target systems, it must be some sort of default configuration.
> "This thing is packaged for anything, in some cases it’s enabled by default, in others it’s not, go figure . Full disclosure, I’ve been scanning the entire public internet IPv4 ranges several times a day for weeks, sending the UDP packet and logging whatever connected back. And I’ve got back connections from hundreds of thousands of devices, with peaks of 200-300K concurrent devices. This file contains a list of the unique Linux systems affected. Note that everything that is not Linux has been filtered out. That is why I was getting increasingly alarmed during the last few weeks."
The 9.9 issue is the foomatic-rip vulnerability; not cups-browsed listening on 0.0.0.0. See here:
> LAN: a local attacker can spoof zeroconf / mDNS / DNS-SD advertisements (we will talk more about this in the next writeup) and achieve the same code path leading to RCE.
You do, until someone finds a way to exploit the other buffer overflows. But also, this attack is persistent: you get infected without any interaction at the coffee shop, and two years later when you print something at home on your well secured network: BAM!
Uh, how? Unless somehow it stays around even though you've left the network (which I didn't think happens, but I could be wrong), this lasts just as long as the mDNS attacking server is on the network?
This to me feels like the author missed why the system was set up the way it was, and therefore doesn't present useful solutions.
The attacker sends a malicious UDP datagram to the target computer, telling it is a printer available at ATTACKER_CONTROLLED_URI.
The vulnerable computer receives this packet and proceeds to download the "printer information" (attacker-controlled printer scripts) from ATTACKER_CONTROLLED_URI and store it in a PPD file as an available printer, potentially overwriting an existing printer.
There is no user intervention needed, nor any notifications to the user, up to this point. The PPD files are persistent: they will stick around ~forever on your system until some other printer replaces them, or you manually delete them.
Whenever you want to print, CUPS looks for all the PPD files currently on the system and provides print options based on them. If you choose to print using the malicious printer (which might look like one of your known printers), the information in the attacker-controlled PPD file will be used by CUPS, including Foomatic scripts that can run more or less arbitrary code with root privileges.
The biggest issue with all of this is that Linux doesn't distinguish between trusted LANs, where arbitrary printers connecting to you is actually a pretty nice feature; and public untrusted LANs, where this is DEFINITELY not a good idea. Also, the fact that your printer infra can run arbitrary code as root, code supplied by the remote printer itself, is another level of crazy.
> Linux doesn't distinguish between trusted LANs [...] and public untrusted LANs
Gotta be the annoying and point out here that Linux is a kernel. Fedora Workstation, for instance, has firewalld installed & enabled by default, which does apply different policies to different network zones. Hook a default system up to a hostile coffee shop, and TCP/UDP ports <= 1024 are blocked by the default FedoraWorkstation zone. NetworkManager connections have a 'zone' property that the user can change to 'home', 'trusted', etc.
> Also, the fact that your printer infra can run arbitrary code as root, code supplied by the remote printer itself, is another level of crazy
Only, it seems, if non-default legacy printer drivers (foomatic) and discovery services (cups-browsed) are present. And doesn't cups run backends as an unprivileged 'lp' user? And confined by MAC (again, in the Red Hat world, SELinux confines it to the cupsd_t domain). So not _that_ crazy.
Disabling foomatic seems hard since the PPD can be distributed by the attacker and foomatic-rip is part of the cups-filter package. But yes, lp user + SELinux should be enough to make this not a 9.9.
I actaully didn't realise that foomatic is part of cups-filters now?! On the other hand - it's only 'activated' by cups-browsed, if I understand correctly, at least by the currently disclosed set of vulnerabilities... let's hope an attacker can't craft a printer that will trick cups itself into configuring a dodgy print destination...
Oh, I get the flow. Only what I'd seen previously is the cups-browsed PPDs only last as long as the source is around (which again, is what I'd seen previously, but I haven't verified the code to see when the cleanup happens, so I'm 100% ready to be wrong). Hence the objection to the "2 years later" comment.
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).
I believe you'd still need cups-browsed installed, enabled & configured to accept remote printer broadcasts, _and_ have foomatic installed locally in order to get hit by this.
Modern version of cups will basically only talk to "driverless" IPP Everywhere printers, which all understand a common set of raster formats and hence have no need for printer-model specific software like foomatic-rip to be installed. They do this via mDNS, which means you don't need cups-browsed to be installed either.
The likely target that emerged in my mind reading this is mom and pop point of sale systems.
The operators of such systems are completely oblivious to such risks, and the underpaid PoS software support team following a script to restart CUPS probably are as well.
It is irrelevant for many desktop Linux users but some distros will have installed the vulnerable software by default on desktop installations and exposed it to the network. That could make it relevant for some percentage of the small percent of people who use desktop Linux and haven't applied security updates and have network misconfiguration or other vulnerabilities exposing their machines. On a scale from 0 to Crowdstrike it is basically a 0 in terms of real impact. It is still great example of an astonishingly stupid by design vulnerability that should not exist or have survived review.
Windows does have a significant mitigation: whenever you connect to a new network, such as a coffee shop Wi-Fi, it defaults to considering this network Public (untrusted) and firewalls any such services from accessing it/being accessed from it. You have to explicitly set it as a "Private" network for file sharing and printer discovery and similar to work.
Only if the machine is directly connected to the internet and the malicious packet doesn't hit a firewall somewhere along the path.
Most laptops connected to Wi-Fi are indeed connected to an AP or a SOHO router that does NAT, so the attacker won't be able to directly reach it and this is a requirement for this to work.
Sure but security isn’t about being 100% protected which is impossible, but lowering your attack foot print. Unless you have a ton of people hooking to your LAN regularly then this still greatly lowers you chances of getting hit with this particular security flaw by people on the WAN
A useful target might be university networks, although IIRC our university printers weren’t available for discovery. Instead we would send our documents to a special email that would forward it to a local print server so we could get charged for it.
I remember there was some like viral marketing thing some company did a while back where they had a website where they had a webcam pointed at a printer, and anything printed would go on a conveyer belt and fall into a literal dumpster fire. Users could submit stuff on their website and see it printed and burned live.
...anyways, maybe they were vulnerable to this attack at the time?
> 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.
In isolation (which is what CVSS is all about) this is not a network exploitable vulnerability, even if you can craft an attack chain which exploits it over the network.
So:
AV:N -> AV:L - reason above
AC:L - correct
PR:N -> PR:L - to exploit this you need to get cups to process a PPD file. Ignoring how it got there, writing a PPD file requires low privileges on the local machine (unless I'm wrong and you can't add a printer to cups as a local user by default, in which case this becomes PR:H with an overall score of 7.7). These might be fulfilled by another component of the attack chain, but again, you need to strictly think in terms of the vulnerability in a vacuum.
UI:N -> UI:R - that a user must perform a task after you begin exploitation in order for the exploit to complete is a classical example of required user interaction
S:C - correct, attacking cups and getting root on the whole machine is considered a scope change
C:L -> C:H - Running arbitrary code as root on a machine is a total breach of all confidentiality of the local machine, so not sure why this was marked as low.
I:H - correct
A:L -> A:H - Running arbitrary code as root on a machine lets you do anything to completely disable it permanently. Availability impact is high.
In summary a score of 8.2 (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H) for CVE-2024-47177 in a vacuum.
There are also buffer overflows exploitable without any user action. The foomatic vector which requires print job was just one easiest to scan and exploit.
Thanks, I missed that. But that still leaves us with only 300 thousand exploitable instances in the whole public IPv4 address space. This is nowhere near a universal GNU/Linux RCE. Of course it's still a big deal to those affected servers, but it's nowhere near even RegreSSHion.
Generally, CUPS on a Mac is bound to localhost. It is highly atypical for a Mac to make it so any computer on the internet or even local network can make requests to its cups server.
The problem isn't CUPS itself, it's the automatic printer discovery mechanism. That's cups-browsed on Linux, not sure how it's achieved on a Mac.
And the printer discovery service can't be firewalled: by definition, it has to listen for outside connections to be in any way useful. This is where things like Windows' trusted VS untrusted networks make sense: it's perfectly nice to allow printers to register to your system on your home network, it's a horrible idea when you connect to an airport wifi.
The 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.
> The standards-based, open source printing system developed by Apple for iOS®, iPadOS®¹
ships on iOS® and iPadOS®.
But maybe it doesn't.
¯\_(ツ)_/¯
In seriousness, exposing only a very limited interface to a flexible, capable system seems to me very on-brand for Apple.
Maybe they don't iOS and iPadOS to be of the kind of platform where one thinks about drivers, even if exposing CUPS features to users would let users accomplish more without much trouble.
Or maybe they see printer drivers as essentially a legacy feature in the face of a 'driverless' future.
Not my cup of tea, but both seem like things leaders at Apple would do/think.
Yes, and CUPS was used on macOS, from which iOS was forked before Apple releases the first iPhone. And from that same year (2007) until 2019, Apple employed the creator and chief maintainer of CUPS, which is presumably how they got their hands on the cups dot org domain. Then (as is typical of Apple's treatment of open-source), Apple stonewalled outside contributions and public releases became increasingly sparse and insignificant. So the creator and longtime ch8ef maintainer of CUPS, now outside Apple, created a new fork under the OpenPrinting banner. Thus CUPS became 'Apple CUPS' and the 'CUPS' everyone else cared about was now OpenPrinting CUPS.
My point was that Apple's language on the website indicates that they probably use CUPS on iOS and iPadOS, not that that language describes CUPS' origins or is informative about the nearly three decade history of of the software or the current landscape of its forks. (Although in fairness to Apple here— a company of which I am not a fan— 'developed by' doesn't mean the same thing as 'authored by' or 'created by'.)
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.
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.
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.
> 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.
The whole thing looks severely overstated. If i was in bad faith i'd say the guy is looking for fame.
I wonder, has the guy tried reproducing the exploit on RHEL/Fedora or some other SELinux-protected system? Because this looks like the kind of issue that SELinux would protect you from:
1. cups likely does not have permissions to go and write executable binary files around
2. cups likely does not have permissions to go and exec binaries without the appropriate labels
If that's the case, this would really be a testament to SELinux and the final blow to AppArmor or whatever Canonical is shipping nowadays (clearly useless).
Are you suggesting that people should not report remote command execution vulnerabilities when such vulnerabilities are successfully stopped by SELinux?
Also, why do you think that seeking recognition for your efforts a bad thing?
> Are you suggesting that people should not report remote command execution vulnerabilities when such vulnerabilities are successfully stopped by SELinux?
No, I'm suggesting that only testing on system shipping weak protection systems and poor defaults is misleading.
> Also, why do you think that seeking recognition for your efforts a bad thing?
It isn't by default, but it can become a bad thing when you overstate the importance of your finding: see my previous line in this comment and add the fact that this guy picked a cve score of 9.9 where heartbleed had "only" a 7.5 score -- but heartbleed affected pretty much everybody in the industry.
> But here’s a screenshot from the VINCE report of the initial CVSS scores, including the 9.9, being estimated by a RedHat engineer (and also reviewed by another one)
> As I said, I’m not an expert, and I think that the initial 9.9 was mostly due to the fact that the RCE is trivial to exploit and the package presence so widespread. Impact wise I wouldn’t classify it as a 9.9, but then again, what the hell do I know?
> No, I'm suggesting that only testing on system shipping weak protection systems and poor defaults is misleading.
But then he would not have found and reported the vulnerability, yet it would still exist and affect people.
Once the vulnerability was discovered it doesn’t matter if one operating system or the other has protections in place that will stop it. What matters is that the code is vulnerable and that there are people who are not protected. Proving that it is not exploitable on systems configured a certain way does not invalidate the original finding.
Hard disagree. FS permissions take like 5 minutes to explain and then you maybe need another 30 minutes in total to try around and get a hang of it. I've given up on selinux every time I've tried to make sense of it. Open 3 different tutorials, have 3 totally different approaches to it.
I guess if you only install core packages on redhat and never touch a single config file it might work OK even for the average Joe.
I found that for me, SELinux is best mastered by reading the documentation. Most tutorials I read when trying to make custom policies and monitor how policies were working, were hot garbage written by people who were just reading other people’s tutorials. SELinux solves problems orthogonal to FS permissions, and use cases that FS permissions alone don’t address.
It was a bit tough at first but writing your first SELinux profile is a fantastic way to make it approachable. YMMV, of course.
> The first thing many do in the real world, after installing RHEL or the free derivatives is ... turn off SELinux.
The people with port 631 publicly reachable didn't configure their firewall either (neither at OS level nor at infrastructure level) so what now, firewalls are useless?
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.
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.
It's not that. Apparently, several major Linux distros, and the cups-browsed developers, have decided for people that any device on the internet should be able to connect to their system as a printer.
Firewall lets it through: cups-browsed explicitly listens for printers advertising themselves. If it's firewalled off, how can it receive the printer advertisements?
I don't know what default firewall rules are configured, but on distros that run it I'd assume it's allowed through, otherwise no reason to run it.
That should protect you from Internet-based attackers, but it doesn't protect you from attackers on the same LAN. For example, if you're in a coffee shop and using their free public wifi, an attacker in that same network can trigger this.
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.
Heartbleed is a memory leak, this is a full RCE without user action - RCE obviously implies full information leakage, and more. Specifically the execution is delayed until the next time a user uses their own printer (which config has been substituted by the attacker). And the vulnerability is in cupsd-browser, not cupsd.
The author may have some attitude problem, but this is a legit Big Deal vulnerability.
It's RCE (as the lp user, if I'm not mistaken) with user action, and only if the firewall isn't blocking required ports. Most systems, even most systems with CUPS installed, never print anything. The number of systems with no firewall (where "firewall" here could just be NAT) that actually print something is even smaller.
CVSS scores are meaningless in a vacuum, and in this case it seems the redhat person who calculated them took the "fudge it until it looks bad" approach.
Below is my professional scoring evaluation while trying to keep to the ideas behind CVSS and the spec as much as I can. Although CVSS is used so rarely in my work (as it usually inappropriate) that I may have made some miscalculations.
If I apply the same exact approach to scoring Heartbleed I get:
7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
The key differences between Heartbleed and the final code execution issue in the attack chain are that Heartbleed is directly over the network (in a vacuum) whereas the code execution is entirely local (in a vacuum, ignoring the previous elements of the attack chain, assuming they were themselves fixed). Additionally with heartbleed there is no user interaction required which also raises the score. But conversely, the direct impact of heartbleed (ignoring what you can do with the information) is that it is only a confidentiality impact (although you could argue that it can lead to a crash which would be a low availability impact bringing the score up to 8.2).
I don't think this clarifies much about the scores but hopefully you can see why CVSS scores are meaningless without any context. You need to put them in the context of the environment. The other problem is that in an attack chain, the overall outcome might be bad even if all the individual issues score low. But CVSS doesn't apply to attack chains.
At the end of the day, this is a high risk issue (you say many distros have cups listen on loopback, but I think this is not true, 631 tcp is indeed loopback only, but 631 tcp is in fact commonly bound to 0.0.0.0) but only in the context of your laptop which you happen to connect to untrusted networks without a firewall.
In summary:
This problem as a whole primarily affects desktop systems and some servers.
Device running cups exposed to the internet: Critical
Device running cups connected to untrusted (but local/non internet routable) networks: High
Device running cups connected to trusted networks: Medium
Sure, but that is equivalent to removing the vulnerable service entirely and the features it was offering. Listening on port 631 for connections from any machine is the entire purpose of cups-browsed, it's the only way to do automatic printer discovery. If we think the port should be closed, then Ubuntu and the other distros should also remove this service, at least from the default installations.
They run their own software, not cups.
the one i had was using their own software, if they had used cups it would have much less problems with printing.
I am slightly confused. If I am using a linux laptop with cups do I need to do anything besides update? Is there a sane way to print from the linux desktop. I unfortunately need to regularly print, and often from public wifi.
Not an expert, but I guess that simply enabling the firewall should avoid most problems related to this vulnerability. In Ubuntu, this can be accomplished with:
Unless you are exposing CUPS to other people on purpose so that you act as a print server then block inbound access using a local firewall. Your local print jobs should be able to use the loopback just fine. Your print spooler would then be talking to the IP on your printer and that should also be confined to your local network and may have optional features to further secure access.
On a very loosely related note, some enterprise printers have optional features to lock down remote access to people that are authenticated. Authentication capabilities vary by vendor. This is somewhat unrelated to CUPS but probably a good time for people to research what their printers can do as printers are a great way to steal company secrets.
[Edit] What smokel said. They beat me to it before I refreshed the page.
This is a misunderstanding of the vulnerability. The problem isn't with the print server. It is with the printer discovery mechanism, cups-browsed. That is the service that listens on the entire network, because it's designed so that LAN printers can advertise themselves to your system.
In that case one can disable it until it is patched assuming there isn't a udev rule that re-enables it. I stay clear of systemd these days so I don't know.
Unless you need printer discovery, you should probably shut down and remove cups-browsed entirely. Its whole purpose is to listen on the LAN to discover printers (or attackers) that advertise themselves to it.
The original CVSS score on Twitter indicated that user interaction was not required. However reading the RCE chain on the page says:
Wait for a print job to be sent to our fake printer for the PPD directives, and therefore the command, to be executed.
If Alice never hits print it seems like a print job will never be triggered. Am I missing something? I'm not questioning evilsocket, I'm trying to check my understanding.
There are also buffer overflows which they detected with fuzzer, which can be turned into RCE without requiring user interaction. But author did not have enough expertise in this area to create actual exploit for these.
It depends on the definition of "interaction". AFAIU Alice doesn't need to print anything supplied by the attacker. It's enough if she prints anything.
I agree that Alice just needs to print anything but that seems like user interaction required. Its also not clear if Alice has multiple printers defined does it matter which printer she selects?
The attacker can replace any and all printers, so not entirely. I'm not sure how the UI part of CVSS is specifically defined, but I think it's at least somewhat fair to call something the user is expected to do unrelated to the attack in any way "no interaction". Otherwise, it's like saying "the user has to power on their device and turn on their Wi-Fi for the attack to work, so it requires user interaction".
The question I had is whether the attacker can enumerate known printers, too. Replacement is a lot more damaging if they don’t have to discover the name of your default printer first.
The interaction question is complicated because there are three modes: the most damaging is when the attacker can trigger the exploit directly, since that’s where we start seeing worms and other untargeted attacks. The next level is where the attacker can exploit something the user normally does - hence the question about default printer replacement since that is something the user has done many times before and thinks of as safe. The lowest level of risk would be if they need to get you to click on a different printer: still bad but nowhere near as easy to exploit on a large scale.
Depending on your interpretation of the Scope metric in CVSSv3, this is either an 8.8 or a 9.6 CVSS to be more accurate.
In summary, there's a service (CUPS) that is exposed to the LAN (0.0.0.0) on at least some desktop flavors of Linux and runs as root that is vulnerable to unauth RCE. CUPS is not a default service on most of the server-oriented linux machines like Ubuntu Server or CentOS, but does appear to start by default on most desktop flavors of linux. To trigger the RCE the user on the vulnerable linux machine must print a document after being exploited.
Evilsocket claims to have had 100's of thousands of callbacks showing that despite the fact most of us have probably never printed anything from Linux, the impact is enough to create a large botnet regardless.
Having a public ip address doesn't always mean there's no firewall in between a pc and the public internet, ideally with sensible default rules. It's not 1996.
And sorry if I'm being a bit harsh on this, but this point comes up every time when ipv6 is mentioned, by people that clearly don't understand the above point.
Just to add a datapoint to the previous comment, my large public US university hands out public IPs to every device on WiFi. If there is a firewall, it doesn't block 8080 or 22.
The point is that, if printing works for those people, then we know they have this port open, at least on the university network. So even if it's not exploitable over the internet, it's definitely exploitable from the whole university network, which is almost as good as from the internet.
Yes. It's rather sad that so many people equate NAT with a firewall. Two totally different things. A firewall is good, NAT is annoying. We need to push IPv6 harder.
But real answer is well if you have arbitrary remote code execution you can also read memory, where as heartbleed only read memory... And the reality is same, you were safe from heartbleed if you did not use openssl, you are safe from this if you do not use cups. CVSS score does not take into account if the software is used or not.
I guess a part of the issue is that it was reported as a "9.9 severity vulnerability in Linux" in a bunch of places, which makes it sound incredibly severe, whereas a "9.9 severity vulnerability in CUPS" doesn't
Uh, Linux desktops have a marketshare of some 4.5% (excluding ChromeOS which isn't affected). Even if most of us don't print (I haven't in the last year and little in the previous five), that will still be a lot of print jobs emitted by Linux hosts.
342 comments
[ 4.8 ms ] story [ 282 ms ] threadHyped 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
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.
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.
https://x.com/evilsocket/status/1838169889330135132
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.
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.
> 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.
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.
has the president been briefed yet?
it's not a complete disaster like it was implied to be though
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?
> 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.
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.
--
https://www.cups.org/
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:
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/
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
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.
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.
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.
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.