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.

That's nearly as many as Code Red and roughly 100K more than SQL Slammer.

    ≻ ps aux | grep -i cups
    xxxxx    31407   0.0  0.0 410741456   1600 s000  S+    3:18pm   0:00.01 grep --color=auto -i cups

It also mentions:

> I can tell you that there’re other, more easily exploitable code paths going on, not just in the discovery mechanism - also reported and ignored. To this day they have not been acknowledged or patched.

Printing something at some point arbitrarily later on the system is almost certainly not classed as User Interaction in this sense.

How do they get around the built-in firewall that's been standard on home routers for the past 15 years?

People who already have some level of fame often feel pressure to keep meeting "expectations".

It is a great way to show which people care about security.

I equate (and I am likely not alone) that this would be a modern equivalent of chmod -R 777 / in early Unix computing.

Use of AppArmour/SElinux is probably a good filter during an interview to determine if a person is a good fit for a security conscious position.

> 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?

If you want to get fired, sure!

> 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.

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.

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.

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

OpenSUSE

But it looks like cups-browsed is only needed on the Internet; locally you only need mDNS.

MX Linux

on popOS I see 0.0.0.0:*

I'm not sure why it deviates from Debian and Ubuntu which its based on though

cupsd is configured to listen locally, but cups-browsed has to listen on the network to do its job (network printer auto-discovery)

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.

Why isn't the firewall on by default on desktop systems?

FWIW, on OpenBSD, cups-browsed is not on my system, but there are some cups files.

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.

Why does it need to run as `root` user and not `cups`?

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.

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 always funny to me how cybersecurity always seem to attract people with a ... certain sense of ego.

Non-loginwalled link: https://threadreaderapp.com/thread/1838169889330135132.html

Or any malicious user on the airport wifi. The compromise will linger until however many weeks later when you decide to print something...

i knew there was a reason i blacklist unsolicited/unauthenticated UDP inbound.

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.

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.

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.

Great opportunity to expand the Sci-Hub effort /s

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

I’d shift that a little earlier (XF86 autoprobing worked for a lot of hardware by the turn of the century) but especially also recognize the competitive environment. Mac, Windows, OS/2, etc. users had been using local network discovery since the 80s, and the people trying to popularize Linux on the desktop were all too aware of the “by and for computer nerds” reputation they were trying to shake, and a lot of people still thought about corporate networks as isolated enclaves where nothing too dangerous happened. The threat model for a lot of people, even server admins who should have known better, was more along the lines of “someone will print a picture of their butt on your desktop printer” rather than “your workstation is now being used to attack the accounting system”.

Used to be XF86Config (even on non-*86). Xorg came in something like 2005. These things are really pretty young still.

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 attack can overwrite the real printer with a fake one.

in the middle of the alley

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.

Every printer vendor does things differently, every printer has different constraints and options? Too many standards?

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...

There may be something else for that.

> 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 run Linux and have been for 10 years. There have been many vulnerabilities with CUPS over the years and its generally known as being risky.

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?

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.

>Is that an exact quote?

It is.

https://x.com/evilsocket/status/1838169889330135132

> 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.

A fair point, although nmap does list results as "closed", "open" or "open/filtered".

Which can be ambiguous if the port is open or firewalled.

However, if the nmap reports that port is "closed," it most likely is:

   Starting Nmap 7.92 ( https://nmap.org ) at 2024-09-26 20:02 EDT
   Nmap scan report for [host] (localip)
   Host is up (0.00084s latency).

   PORT    STATE  SERVICE
   631/udp closed ipp

I'd add that GP specifically requested an nmap command.

All that said, you're absolutely correct and if nmap returns something like this:

   Starting Nmap 7.92 ( https://nmap.org ) at 2024-09-26 20:04 EDT
   Nmap scan report for [host] (localip)
   Host is up (0.00058s latency).

   PORT    STATE         SERVICE
   631/udp open|filtered ipp

then further poking could be required, as you suggest.

I would point out that cups-browsed isn't really necessary unless you desire to have printers automatically added without any user interaction. Which is poor opsec in any situation.

If we're talking about a corporate environment, adding printers can be automated without cups-browsed, and at home or in the wild (cafes, public wifi, etc.) that's an unacceptable (at least from my perspective) risk and printers (if needed in such an unsecured environment) should be explicitly added by the user, with manual checks to ensure it's the correct device.

As such, rather than checking to see if cups-browsed is running unsecured, simply check to see if it's installed:

Debian and variants:

   'sudo apt list --installed | grep cups-browsed'

RedHat/Fedora and variants:

   'sudo rpm -a -q | grep cups-browsed'

And if it is, remove it.

Edit: fixed typo.

You can use --data in nmap to send it easily to the range of hosts (but the server is still needed).

Maybe, but it’s good practice to verify that your reload is clean when you are actively working on it.

You are right of course, but the default policy can be changed using "ufw default allow incoming", making "deny" necessary. You might do it on a laptop/workstation (in a network firewalled from the internet), though it doesn't sound like a great idea to me.

I prefer explicitness when it comes to configuring firewalls. Both for documentation and to guard against defaults changing underneath you.

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.

There are a few clients here: https://github.com/topics/ipp

It's not hard to write a client library / CLI, it's just there isn't much interest.

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

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.

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.