Friday, September 27th 2024
New Linux RCE Vulnerability Leaks Ahead of Disclosure - Allows Arbitrary Code Execution via CUPS Print Scheduler
A new vulnerability was recently discovered in a widely used print server that is installed by default on many Linux and Unix-based systems with a graphical user interface. The primary attack vector for the vulnerability is the CUPS (Common Unit Printing System) print scheduler, specifically cups-browsed, and has the potential to execute code remotely with zero user interaction required.
The vulnerability has reportedly been given a CVSS score of 9.9 by RHEL and Canonical, although this score is hotly debated, with some arguing it should have a lower score, because, although code can be remotely downloaded to the system, it cannot be executed without user intervention. Fortunately, there is no evidence of the vulnerability having been exploited, although the disclosure was leaked online ahead of a planned private reveal in October, prompting the developer that discovered the vulnerability to post the full explanation in a write-up on their blog. This being the case, the vulnerability could very well start being exploited by malicious actors.
According to the lengthy blog post by the researcher, Simone Margaritelli, services related to the CUPS printing system on are vulnerable to remote code execution. Essentially, an attacking system convinces the print scheduler that it is a printer and sends over malware—which can be arbitrary executable code—that is disguised as a printer configuration file. This process requires no user intervention, since CUPS will accept any packet sent via port *:631. The next time the user attempts to print something, that code can be executed, potentially compromising the system.
While the researcher claims that most GNU/Linux distributions—as well as potentially ChromeOS and macOS—are affected, it should be noted that it is not the default configuration for many Linux distributions, and it especially shouldn't be the case for any large-scale servers or data centers, meaning the largest target group would be private PC users running Linux.
Sources:
Evilsocket Blog, Stong on GitHub Gist, Shodan
The vulnerability has reportedly been given a CVSS score of 9.9 by RHEL and Canonical, although this score is hotly debated, with some arguing it should have a lower score, because, although code can be remotely downloaded to the system, it cannot be executed without user intervention. Fortunately, there is no evidence of the vulnerability having been exploited, although the disclosure was leaked online ahead of a planned private reveal in October, prompting the developer that discovered the vulnerability to post the full explanation in a write-up on their blog. This being the case, the vulnerability could very well start being exploited by malicious actors.
SummaryThe specific exploit depends on a host of unpatched vulnerabilities, some over a decade old, making this a particularly concerning issue for those using Linux or Unix-based. For this attack vector to work, the system needs to have CUPS (Common Unix Printing System) and cups-browsed installed and running, which is the default for a lot of systems. According to Margaritelli, there are 200,000-300,000 systems with the print service currently connected to the internet, although Shodan reports (see above screenshot) that there are around 76,000 systems with open CUPS ports connected to the internet.
- CVE-2024-47176 | cups-browsed <= 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 | 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 | 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 | cups-filters <= 2.0.1 foomatic-rip allows arbitrary command execution via the FoomaticRIPCommandLine PPD parameter.
While the researcher claims that most GNU/Linux distributions—as well as potentially ChromeOS and macOS—are affected, it should be noted that it is not the default configuration for many Linux distributions, and it especially shouldn't be the case for any large-scale servers or data centers, meaning the largest target group would be private PC users running Linux.
31 Comments on New Linux RCE Vulnerability Leaks Ahead of Disclosure - Allows Arbitrary Code Execution via CUPS Print Scheduler
Although I did disable it as well, don't need printing. And I already have ufw on, which blocks inbound connections by default.
Read the config files and change them after installing a package. This was not done!
Only install packages you need.
The news title is wrong. Cups is not broken. Cups-browsed is broken. My gentoo box has the cups-browsed package not installed - but i can print and i can print to pdf.
The bad attitude of bug readers. The bad attitude of many when hinting out issues.
I recommend to make those bugs instantly public after 3 calendar days.
I want to thanks the person who wrote up how he found it.
Not the part that it listens to IPP announcement packets by default - Windows (in Private networks) and macOS do this as well in order to meet user expectations that connecting a modern networked printer will make it magically appear in systems on said network.
The broken part is parsing of those IPP packets in CUPS which leads to RCE because there isn't enough sanitization done on the data they carry. The person who discovered those bugs wrote in the blog that what was made public aren't the only problems he found, so we can expect more reports, and that macOS is also affected.
Just because your custom Gentoo installation doesn't include cups-browsed doesn't mean that it isn't installed by default by more mainstream distributions like Ubuntu, because it is.It shouldn't, in theory.
I think that those detected computers might be Ubuntu or any other mainstream desktop Linux distribution that has been installed on a server instead of using a server distribution. Since Ubuntu installs the vulnerable component by default in their desktop variant, their users might simply not know it's even there. Not everyone is a Linux expert, and installation of a desktop distribution on server that's directly Internet-facing suggests that they aren't either.
In my opinion the automatic discovery should be limited to private networks only, just like it is on Windows. That's an issue of CUPS configuration which is on the distribution maintainer, but it's no excuse for the lax parsing of IPP packets in CUPS.
what is the command line I need to use to disable this and printer entirely in Linux Mint 22? I don't even need printing capability for my laptop, i'd rather it just be gone entirely to mitigate any security issues.
systemctl stop cups
Then you need to disable all of the associated systemd services;
systemctl disable cups.service cups.socket cups.path
Then you need to mask it so nothing else starts it;
systemctl mask cups
Then after a reboot you can make sure this procedure was successful by checking the status;
systemctl status cups
i think im still going to do this though, because i literally have no need for a printer for my work laptop
so if im traveling with my work laptop... connecting to various wifi networks, gg ?
Windows does this as well, but only on networks marked as "Private". When you first connect to a new network it will ask if you want to enable this feature for said network.Yes, CUPS as shipped by most distributions will do this on any network. It's part of the reason this got a 9.9/10 rating. It's a configuration problem that should be resolved by distribution maintainers. It can be changed by the user, but most don't even know this is happening.This issue requires CUPS to listen on the * address (meaning all local IPv4 and v6 addresses), UDP port 631, for printers (or "printers") to connect to it. If you forbid external incoming connections to it by using iptables it will solve the issue. A side effect is disablement of the automatic printer discovery mechanism. Such configuration will still allow you to use external printers by manually adding them since then CUPS is connecting to the printer, as in it's an outgoing connection.