Coker: The CUPS vulnerability [LWN.net]

Debian Developer Russell Coker has written up an analysis of the remote exploit of CUPS announced in September:

He seems to have a different experience to me of reporting bugs, I have had plenty of success getting bugs fixed without hyping them. I just report the bug, wait a while, and it gets fixed. [...] I was quite confident that my systems wouldn't be at any risk.

When it was published my opinion was proven to be correct, it turned out to be a series of CUPS bugs.

to post comments

The original report seems more on the money

Posted Oct 28, 2024 22:37 UTC (Mon) by epa (subscriber, #39769) [Link] (19 responses)

As an outsider I find the original analysis by Simone Margaritelli more persuasive. You can try to wave it away by saying that not all systems run CUPS, or that it's only exploitable over a local network (not behind NAT). But if that's the low bar we are setting you might as well give up security work. It was and is a serious flaw, and while the researcher was a bit snarky in describing the quality of the CUPS code, I can quite understand why.

The original report seems more on the money

Posted Oct 28, 2024 23:43 UTC (Mon) by marcH (subscriber, #57642) [Link] (10 responses)

> You can try to wave it away by saying that not all systems run CUPS, or that it's only exploitable over a local network (not behind NAT). But if that's the low bar we are setting you might as well give up security work.

That was my initial impression, thank you for confirming. I lost count of how many devices and operating systems run on my home LAN and many of them are managed by some external company. So, no: "I'm safe behind my NAT" is simply ridiculous. Any software that listens to any other interface that "localhost"[*] should be paranoid - or uninstalled. I think some people call this "Zero Trust" and it makes a lot of sense to me. Very few people actually understand firewalls and everyone wants to just "be online" without grading networks based on risk, that's a complexity dead-end. Complexity or security: pick one. If you're the network admin for some Big Corp then yes of course you want to segment your giant network so not everything gets hacked at the same time. But here we're talking about CUPS which is running in every _home_ that uses Linux (and macOS?)

[*] I'm not saying services listening localhost should be insecure either but there yes the bar can be a bit lower.

The original report seems more on the money

Posted Oct 29, 2024 2:12 UTC (Tue) by tghoh (subscriber, #139866) [Link] (7 responses)

But the thing with a NAT firewall is any unsolicited traffic (say, UDP to port 631) arriving from the WAN is simply dropped. Any software listening on the LAN is safe from outside connections unless it has opened a connection out through the firewall (assuming a properly operating firewall).
If you are a home user, and you have configured your firewall to forward outside connections to your CUPS server then you have a problem (why you would want the whole world to use your printer may be a bit of a mystery). No forwarding rule - no problem. I have no trouble finding the original claim over-hyped.

The original report seems more on the money

Posted Oct 29, 2024 2:49 UTC (Tue) by pizza (subscriber, #46) [Link] (3 responses)

> If you are a home user, and you have configured your firewall to forward outside connections to your CUPS server then you have a problem (why you would want the whole world to use your printer may be a bit of a mystery). No forwarding rule - no problem. I have no trouble finding the original claim over-hyped.

For example, anyone running a semi-modern RHEL or Fedora system would have to take multiple, deliberate steps in order to be (a) vulnerable, (b) exploitable, and (c) have the attacker gain access to anything "interesting":

0) If it's a server, install+enable CUPS to begin with
1) Directly attach their system to the internet (or configure their firewall/router to automatically forward the port)
2) Disable (or otherwise open up) the local system firewall
3) Enable(+start) cups-browsed
4) Disable SELinux
[ Get attacked, creating a fake printer queue ]
5a) Have "interesting" stuff accessible by the CUPS user or have a local privilege escalation exploit (ie attacking the local system)
5b) Get induced to print to the "fake" printer from a different system with (4) or (5a) in effect.

That's not to say these wern't (embarassingly) serious bugs that shouldn't have been immediately fixed, but there's a huge practical difference between "this door won't shut properly' when it's an exterior door versus one behind a series of other locked doors.

The original report seems more on the money

Posted Oct 31, 2024 13:37 UTC (Thu) by raven667 (subscriber, #5198) [Link] (2 responses)

The thing that I keep coming back to is that there isn't a problem of capability when it comes to network security, every system kernel new enough to have IPv6 support comes with a robust packet filter, desktops have dynamic zone-based rules that can ensure services are no more exposed than they have to be to function, tools like OpenSnitch https://lwn.net/Articles/988401/ exist to provide transparency and audit even for outbound application filtering. There should be no problem having your desktop connected directly to the IPv4 and IPv6 Internet with reachable public addresses because they are protected with the same quality of tools that protect Internet-facing servers, the main problem is UI/UX to make those policy settings visible/managable to the user.

The original report seems more on the money

Posted Oct 31, 2024 18:23 UTC (Thu) by marcH (subscriber, #57642) [Link]

This is not just an UI problem... Firewalling, packet filtering and tools like OpenSnitch are great for _experts_ but pretty much everyone wants printing to Just Work at home. Using _network_ tools on a single host (?!) adds a layer of indirection and complexity that make it totally impossible for mere mortals to manage security. Ask around how many non-technical persons understand and pay attention to Android permissions: very few even though they're generally simpler and more familiar than networking concepts, they only ask "Is app X allowed to use Y?"

So the most complex security questions a UI must ask are:
- Should app X be installed?
- Should app X be running?
- Should app X listen and reply to _remote_ requests?

And that's it. You don't need and don't want an additional firewall and packet filtering layer to interfere with the last question because that's the surest way to misconfigure something and get it wrong: either giving a false sense of security, or overload support with calls about "why things don't work".

In fact, even "experts" can get confused: at $BIGCORP, I once realized that a port was accepting incoming connections on my IT-managed laptop on a supposedly closed port. This was of course not just my laptop.

The original report seems more on the money

Posted Nov 1, 2024 3:29 UTC (Fri) by etbe (subscriber, #17516) [Link]

Yes it is an issue, it should be fixed, and every distribution has done a good job of fixing it.

That doesn't change the fact that it only affects a small portion of the Linux machines out there and is a long way from the kernel or ssh issue that was implied by the initial claims.

The initial announcement would have been better described as a "potential remote root access in non-default configurations without appropriate firewalls" which would have given people a hint to review their firewall settings without getting the wrong idea about the scope of the problem.

The original report seems more on the money

Posted Oct 29, 2024 4:12 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> why you would want the whole world to use your printer may be a bit of a mystery

I did that as an experiment a while ago. After about half a day, I got a well-meaning message saying "your printer is open to everybody" and the Communist Manifesto printed on it.

The original report seems more on the money

Posted Dec 16, 2024 8:29 UTC (Mon) by mrugiero (guest, #153040) [Link] (1 responses)

I don't understand why nobody mentions the very common case of connecting to public wifi at a cafe or an airport. People use laptops, and people connect to public networks. That alone makes a default open port to a vulnerable service a serious issue to look at.

The original report seems more on the money

Posted Dec 16, 2024 13:45 UTC (Mon) by pizza (subscriber, #46) [Link]

> I don't understand why nobody mentions the very common case of connecting to public wifi at a cafe or an airport. People use laptops, and people connect to public networks. That alone makes a default open port to a vulnerable service a serious issue to look at.

It is also the overwhelmingly common case that said laptops are configured with local "deny everything incoming" firewalls. [1]

As in, that's their default post-installation state, and the person sitting in front of them has to take steps to open up an incoming port or disable the firewall entirely.

I'm not saying that this vulnerability should be ignored, but at the end of the day we can't protect against folks that deliberately [mis]configure their systems in a vulnerable manner.

[1] including Windows, MacOS, and most (if not all) desktop linux [2] setups.
[2] I can' t speak for Slackware... or Debian with its ("our choice is to not make a choice") philosophy towards system defaults.

The original report seems more on the money

Posted Oct 29, 2024 9:04 UTC (Tue) by kleptog (subscriber, #1183) [Link] (1 responses)

> I lost count of how many devices and operating systems run on my home LAN and many of them are managed by some external company.

I'm confused about what you're saying here. You say you have devices on your home LAN which you trust being managed by external companies. But on the other hand you're concerned these managed devices might try to hack your CUPS daemon?

If that's your level of paranoia, maybe just configure your home LAN so none of the devices can talk to each other?

The original report seems more on the money

Posted Oct 29, 2024 15:07 UTC (Tue) by marcH (subscriber, #57642) [Link]

> If that's your level of paranoia, maybe just configure your home LAN so none of the devices can talk to each other?

There is very little paranoia in assuming one of the too many devices in a typical home LAN can get hacked. Have you been living under a security rock?

While a lot of LWN readers can probably configure their LAN, the vast majority of the population does not have a clue.

The original report seems more on the money

Posted Oct 28, 2024 23:55 UTC (Mon) by marcH (subscriber, #57642) [Link] (1 responses)

> I have reported potential security bugs without even bothering to try and prove that they were exploitable (any situation where you can make a program crash is potentially exploitable),

Tired of this too...

Yes, but: "potentially" exploitable != exploitable for sure.

So, no: every bug or crash is not automatically a security issue and they should not all be treated the same. Vulnerabilities _are_ a special, worst class of bugs that does deserve special treatment.

The original report seems more on the money

Posted Oct 29, 2024 0:53 UTC (Tue) by pizza (subscriber, #46) [Link]

> Yes, but: "potentially" exploitable != exploitable for sure.

Meanwhile, the number of *potentially* and *actually* exploitable systems is far, far smaller than "OMG EVERY LINUX SYSTEM!!!!11"

The original report seems more on the money

Posted Oct 29, 2024 7:40 UTC (Tue) by LtWorf (subscriber, #124958) [Link] (1 responses)

A bit snarky? :D

The claims prior the release were completely over the top.

I get that security researchers want to increase the impact, but come on…

The original report seems more on the money

Posted Oct 31, 2024 7:11 UTC (Thu) by epa (subscriber, #39769) [Link]

Ah, okay, I didn’t see the claims beforehand, only the analysis. That’s what I was referring to as snarky.

The original report seems more on the money

Posted Oct 29, 2024 23:50 UTC (Tue) by viro (subscriber, #7872) [Link]

It's not just a bit snarky - it's a full-blown science-by-press-conference, and failing to see anything wrong with it.

For further enlightenment, see "cold fusion", "water memory", "arsenic DNA", "Ida", et sodding cetera. Doesn't have to be scam - Darwinius is a quite real and very interesting find, but it had been overhyped to hell and back and authors' interpretation was... not well founded, to put it politely.

The original report seems more on the money

Posted Oct 31, 2024 9:51 UTC (Thu) by Heretic_Blacksheep (guest, #169992) [Link] (2 responses)

I got the opposite impression from the first analysis. The point of security is that there are, indeed, layers. Not all Unix systems have CUPS installed (layer one), it requires LAN access (layer two), no-trust zoning (layer three), perimeter firewall/NAT (layer four), etc. The original analysis explicitly stated "all Linux systems" were vulnerable, which is absolutely *not* the case.

I find your comment equally over the top as if throwing up ones hands and giving up if people don't agree with your take on security is a useful argument. This is a trope to shutdown conversation with those that don't agree with you.

The original report seems more on the money

Posted Oct 31, 2024 13:17 UTC (Thu) by epa (subscriber, #39769) [Link] (1 responses)

Maybe we are talking at cross purposes. I was reading the report at https://www.evilsocket.net/2024/09/26/Attacking-UNIX-syst... which to me seems thorough and correct, although written in a polemic style. I didn't look at any "trailers" or pre-disclosure hype on Twitter or whatever.

It doesn't claim that all Linux systems are vulnerable, but is specifically about CUPS -- noting, correctly, that many distributions install it by default. From my point of view an exploit against CUPS remains a valid exploit and a concern even though, obviously, it doesn't affect you if you don't have CUPS installed.

The original report seems more on the money

Posted Oct 31, 2024 15:05 UTC (Thu) by pizza (subscriber, #46) [Link]

> I didn't look at any "trailers" or pre-disclosure hype on Twitter or whatever.

This "hype" was produced and spread/promoted by the same folks that wrote the actual report.

> noting, correctly, that many distributions install it by default.

So what? NFS and SMB servers also typically installed by default. That doesn't mean they're _actually enabled_ or otherwise configured in such a way that will exfiltrate all of your data to the internet at large.

This set of vulnerabilities handily demonstrates the value of "layers of defense"; I posted earlier with an example of how a RHEL/Fedora system admin would have to perform four or five separate, deliberate steps for these vulnerabilities to rise to the level of a successful exploit. As I also mentioned earlier, it's similar to the difference between your front door being left open versus the door to a bedroom closet -- and in the latter case, the bedroom, hall, and front door are locked, with a watchdog standing guard.

Legit vulnerability, overhyped too

Posted Oct 29, 2024 22:46 UTC (Tue) by martin.langhoff (subscriber, #61417) [Link]

The vulnerabilities reported are/were legit. Even in non-default configurations, etc, they are entirely valid reports.

At the same time, the grandstanding wasn't justified. Serious, but of limited impact. The wording in the Twitter post made many folks expect an ssh or kernel Remote Exec.