Is this the CUPS hell? Maybe not for everyone, methinks
I don’t address security issues. I don’t fix vulnerabilities. But I am so tired of reading about such things! And believe me, I read about them a lot. For decades already. And I’m so pissed off!
Too bad I read The Reg
A couple of hours ago: Doomsday ‘9.9 RCE bug’ might hit every Linux system. Hey, not so fast!
Meanwhile, the article got updated, so I’ll quote from their TL;DR:
In short, if you’re running the Unix printing system CUPS, including cups-browsed, then you may be vulnerable to attacks that could lead to your computer being commandeered over the network or internet.
The bugs were found and disclosed by software developer Simone Margaritelli who has now openly disclosed the issue in detail here.
What you need to know for now, according to Margaritelli, is:
- Disable and/or remove the cups-browsed service.
- Update your CUPS installation to bring in security updates when available.
- Block access to UDP port 631 and consider blocking off DNS-SD, too.
- It affects “most” Linux distros, “some” BSDs, possibly Google ChromeOS, Oracle’s Solaris, and potentially others, as CUPS is pretty widely included in distributions.
- To exploit this across the internet or LAN, a miscreant just needs to reach your CUPS service on UDP port 631. Hopefully none of you have that facing the public internet anyway.
- If port 631 isn’t available, an attacker may be able to spoof zeroconf, mDNS, or DNS-SD advertisements to achieve exploitation. Details of that path will be disclosed later. In fact, more details are promised.
If you don’t have CUPS and/or cups-browsed on your system, you’re good. If you were already firewalling off CUPS, you’re most likely good.
Nah. More links:
- Here’s a copy of the CUPS disclosure (just in case)
- Phoronix: Unauthenticated RCE Flaw With CVSS 9.9 Rating For Linux Systems Affects CUPS
- Review locking/multi-threading implementation #36
- Multiple bugs leading to info leak and remote code execution
- cfGetPrinterAttributes5 does not validate IPP attributes returned from an IPP server
- ppdCreatePPDFromIPP2 does not sanitize IPP attributes when creating the PPD buffer
- Command injection via FoomaticRIPCommandLine
- Multiple bugs leading to info leak and remote code execution
- CVE-2024-47176 | Severity: 8.4 (HIGH) |
cups-browse
d <= 2.0.1 binds on UDP INADDR_ANY:631 trusting any packet from any source to trigger a Get-Printer-Attributes IPP request to an attacker controlled URL. - CVE-2024-47076 | Severity: 8.6 (HIGH) |
libcupsfilters
<= 2.1b1 cfGetPrinterAttributes5 does not validate or sanitize the IPP attributes returned from an IPP server, providing attacker controlled data to the rest of the CUPS system. - CVE-2024-47175 | Severity: 8.6 (HIGH) |
libppd
<= 2.1b1 ppdCreatePPDFromIPP2 does not validate or sanitize the IPP attributes when writing them to a temporary PPD file, allowing the injection of attacker controlled data in the resulting PPD. - CVE-2024-47177 | Severity: 9.1 (CRITICAL) | cups-filters <= 2.0.1
foomatic-rip
allows arbitrary command execution via the FoomaticRIPCommandLine PPD parameter.
And then, from the horse’s mouth:
From a generic security point of view, a whole Linux system as it is nowadays is just an endless and hopeless mess of security holes waiting to be exploited.
Impact
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).
Entry Points
- 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.
Remediation
- Disable and remove the
cups-browsed
service if you don’t need it (and probably you don’t).- Update the CUPS package on your systems.
- In case your system can’t be updated and for some reason you rely on this service, block all traffic to UDP port 631 and possibly all DNS-SD traffic (good luck if you use zeroconf).
Entirely personal recommendation, take it or leave it: I’ve seen and attacked enough of this codebase to remove any CUPS service, binary and library from any of my systems and never again use a UNIX system to print. I’m also removing every zeroconf / avahi / bonjour listener. You might consider doing the same.
What is cups-browsed?
After some googling I found out that
cups-browsed
is indeed part of the CUPS system and it is responsible for discovering new printers and automatically adding them to the system. Very interesting, I had no idea Linux just added anything found on a network before the user can even accept or be notified. The more you know!
The 9.9 CVSS severity proved to have been an exaggeration. As for the more technical parts, I’ve read them, but I won’t try to comment on them.
My take: appeasement is the name
■ This is not the end of the world.
■ CUPS is a piece of shit. I wanted we never had this “technology.” It’s antiquated in spirit and stupid in design. I never liked it.
■ Open-source as it is, did you know it’s owned by Apple? The creator of CUPS, Michael Sweet, on his last day at Apple: “CUPS is still owned and maintained by Apple. There are two other engineers still in the printing team that are responsible for CUPS development, and it will continue to have new bug fix releases (at least) for the foreseeable future.” Wow, two engineers! Apple is spoiling us.
■ You can’t print in Linux without CUPS.
■ I’m pretty sure Windows is affected too, to some extent.
■ The “Zeroconf / Avahi / Bonjour listeners”: Apple’s Bonjour service is available for Windows (it even worked with Win2k); Win10 added support for mDNS; zero-configuration networking means Avahi in Linux, but systemd-resolved
might also be involved (for mDNS).
■ Attacks from a LAN are unrealistic on a home network, and very unlikely in most offices. (Of course, I don’t know your kids and your colleagues, I was just saying.)
■ Attacks from the WAN are even less likely, despite the above warnings, because you are not connected directly to the Internet. You have a router between the LAN and the WAN. The router includes a firewall. Even if it didn’t, the router uses NAT to help the communication between networks by translating the private addresses of your LAN to your public WAN address. Your computer is not directly visible from the Internet, unless:
- You configured Port Forwarding in your router, and your computer is the one receiving packets that might exploit a vulnerability on your system, such as UDP packets on port 631. Did you do that?
- You configured a DMZ for your computer, meaning it’s as if it were on the Internet: the NAT makes your computer receive everything that targets the public IP. I’m sure you didn’t do that.
■ I will certainly not “remove any CUPS service, binary and library from any of my systems and never again use a UNIX system to print.”
■ Medium and large organizations should be worried, though. It’s not my fault that the entire printing on a planet with 8bn people relies on something developed by 3 people at Apple!
■ Funny thing, CUPS and zero-configuration networking did not exist in the times of Win3.1, Win95, and Win98. Those were the times!
■ Oh, it was worse back then? Maybe so, but they certainly didn’t have this: “discovering new printers and automatically adding them to the system.”
■ This is not a bug as in “some sloppy coding.” This is the combined effort of a bunch of retards who designed this AUTOMAGIC. I hope they get colon cancer.
UPDATE: Canonical and Red Hat step in
A random site, OMG! Ubuntu, tells you not to panic:
If you use a firewall or NAT router that blocks the port affected, you were likely never vulnerable to this.
You do. Now, for the corporate response:
- Canonical: CUPS Remote Code Execution Vulnerability Fix Available.
- Red Hat: Red Hat’s response to OpenPrinting CUPS vulnerabilities: CVE-2024-47076, CVE-2024-47175, CVE-2024-47176 and CVE-2024-47177. Red Hat didn’t issue any fix yet for RHSB-2024-002 – OpenPrinting cups-filters, and all RHEL versions are affected.
Let’s examine Canonical’s response, which is brilliant compared to Red Hat’s:
The following mitigation steps remove a print server’s ability to detect new network printers and stop the injection of the malicious PPD file:
- Edit
/etc/cups/cups-browsed.conf
- Search for the
BrowseRemoteProtocols
configuration option- Set the option to
none
(the default value is “dnssd cups
”)- Restart
cups-browsed
usingsystemctl restart cups-browsed
Then, about those fixes:
- CVE-2024-47076:
24.04 LTS noble: not affected (cups-filters
), FIXED (libcupsfilters
);
22.04 LTS jammy & 20.04 LTS focal: FIXED (cups-filters
), not usinglibcupsfilters
. - CVE-2024-47175:
24.04 LTS noble: FIXED (cups
,libppd
);
22.04 LTS jammy & 20.04 LTS focal: FIXED (cups
), not affected (libppd
). - CVE-2024-47176:
24.04 LTS noble: FIXED (cups-browsed
), not affected (cups-filters
);
22.04 LTS jammy & 20.04 LTS focal: not usingcups-browsed
, FIXED (cups-filters
). - CVE-2024-47177: needs evaluation (
cups-filters
).
And 18.04 LTS bionic & 16.04 LTS xenial are both vulnerable to the 2nd and 3rd CVEs, but for a swift response, this is amazing!
But I still hate the CUPS architecture.
And Bleeping Computer only noticed Red Hat’s mitigation measures, which are brutal and tell you to disable cups-browsed
. Canonical not only provided fixes, but even without them, it also told you how to remove a print server’s ability to detect new network printers without stopping using cups-browsed
. 👌
Risky Business News: Attackers are on the hunt for the new UNIX CUPS RCE (Sep 30, 2024)
I wanted to comment further on this, but for lack of time, only this excerpt: