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.
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.
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.
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.
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).
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.
This is entertaining reading. Although I don't know how pervasive this issue is, from the chunk i have read so far I can see why he was concerned that it was relatively trivial to have a target system accept anything identifying itself as a printer and being able to inject malicious code into the machine.
I was going to make fun of him wasting his sabbatical on hacking a printer service but I gotta admit I'd have fallen down the same rabbit hole if I stumbled on it. It's a cool hack.
- An attacker can exploit this vulnerability if it can connect to the host via UDP port 631, which is by default bound to INADDR_ANY, in which case the attack can be entirely remote, or if it's on the same network of the target, by using mDNS advertisements.
What does an attacker gain by exploiting this vulnerability?
- Remote execution of arbitrary commands when a print job is sent to the system printer.
How was the vulnerability discovered?
- A lot of curiosity (when I noticed the \*:631 UDP bind I was like "wtf is this?!" and went down a rabbit hole ...) and good old source code auditing.
Is this vulnerability publicly known?
- No, the bugs are not known and the FoomaticRIPCommandLine vulnerability is known to be already patched (it isn't).
Is there evidence that this vulnerability is being actively exploited?
From an eating-popcorn perspective, I would find it truly entertaining that a printer package could somehow result in a 9.9 security vulnerability that is somehow worse than heartbleed. How many linux systems actually have cups installed and active?
I think the Chinese perspectives of how a war against Taiwan might proceed was dramatically altered after watching Russia get slapped around by Ukraine. I'm convinced it delayed any aggressive move by China against Taiwan by a decade, if not more.
There is a theory that the US loses every prolonged conflict by default, because taxpayers eventually lose interest in winning.
China is probably watching the latest developments in US support for Ukraine with great interest. If the support proves insufficient for Ukraine to win, they may conclude that there is no need for a proper invasion of Taiwan. That there is no need for an all-out war. They could just isolate the island, try to shoot down every plane and sink every ship, and take whatever casualties Americans are willing to take. If their navy and air force can match their US counterparts, they just need to spend more and last longer.
Ukraine is (and will continue to be for decades) a fascinating case study for multiple reasons, but most impressively regarding NATO support. Although headlines detail billions upon billions in spending, the vast majority of those expenditures from the NATO side were for the notional values of stuff that was already just sitting around. This has got to be one if the cheapest conflicts--from a taxpayer perspective--they've ever supported, which is amazing considering the success Ukraine has experienced in bringing Russia's military to its metaphorical knees.
I think China would be far more aggressive with Taiwan if the West hadn't frozen Russia's central bank assets. That single move likely had the biggest impact in curtailing any expansionist dreams.
We've got to make it 10 years from now for demographic change.
Great fictional book about a possible 2024 era war, "2034: A Novel of the Next World War", Novel by Elliot Ackerman and James G. Stavridis. It's much more realistic than other novels. China sinks multiple aircraft carriers, they completely hack the us and turn off the power and telecommunications. Then the shit hits the fan. Maybe a limited nuclear exchange will scare the other side, the us and china start thinking.
I was brand new to managing an Ubuntu Hetzner server and the moment I saw how many port 22 scans the server received i decided to try changing the port number, followed by key-only passwordless logins. My logs immediately shrank in size. I have never once had an issue having moved to non standard ports and, moreso, feel almost naked logging into port 22.
I know security through obscurity is not an answer, but judging by the reduction in port scanning i've seen after moving as many standard ports as possible to new addresses above 20000 I have to believe its a reasonable first step. How many script kiddies are scanning all 65500 ports for each IP address?
I feel similarly. Switching ports is no real defense, but it at least means you are eliminating the drive-by attacks who are only interested in the trivially exploited. Such a simple thing to do and sharply reduces the log volume.
The next trick I think of implementing is port knocking. Should drop log noise to zero unless someone starts targeting me specifically. In which case, my goose is already cooked.
If it's not some sort of proxy/firewall remapping the port, you probably shouldn't use a port above 1000 for some services.
Consider this: an attacker (somehow) managed to get user access to your server. They can now dos the service until it crashes and then start their own service listening on that same port, maybe impersonating your service. Maybe they can use that to grab sensitive information or do something else.
Indeed, although because I heavily utilized Docker I also ended up using UFW-Docker. It was fairly straightforward to incorporate into my startup scripts.
Judging by the declaration of war against Ukraine by Russia, it appears an underappreciated aspect of the equation is equal measures of senility and insanity.
