Critical Linux RCE in CUPS — What We Know and How to Prepare
Executive summary
A critical remote code execution (RCE) vulnerability chain, which is believed to affect many Unix-like hosts, was disclosed on September 26, 2024.
The vulnerable component is the Common Unix Printing System (CUPS), specifically cups-browsed.
A chain of four vulnerabilities is required for a successful exploitation: CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177.
In this blog post, Akamai shares details about the vulnerability, analyzes the technical disclosure, and provides recommendations for what can be done to effectively prepare and mitigate the risks while waiting for a patch.
Introduction
On September 23, 2024, security researcher Simone Margaritelli shared details on social media about an upcoming vulnerability disclosure. In his post, Margaritelli described a critical vulnerability that he had disclosed to the developers three weeks prior — an unauthenticated RCE vulnerability that can potentially affect all GNU/Linux machines.
On September 26, 2024, a full technical disclosure was released. There are four vulnerabilities in total:
CVE-2024-47176 in cups-browsed, which coerces a request to an attacker-controlled address
CVE-2024-47076 in libcupsfilters, which does not validate or sanitize data returned from the attacker’s server, and passes it to the rest of the CUPS system
CVE-2024-47175 in libppd, which again involves not sanitizing input, and writing it to a temporary file
CVE-2024-47177 in cups-filters, which allows for an arbitrary command execution
Our goal with this blog post is to help organizations prepare, so that the remediation process is as smooth as possible. To that end, we offer a technical summary of the exploitation chain and some mitigation steps (in the form of segmentation recommendations) that network admins can employ while waiting for the patch.
What can be done to prepare?
For an attacker to exploit an RCE vulnerability, two “pieces” are required: a vulnerable piece of software, and (of course) remote access. Since we know that the vulnerable component is CUPS, we can simply patch it (when the patch becomes available) or apply some mitigation steps specifically for that component, but we believe that the best course of action is to use this opportunity to address remote access more broadly.
Let’s start, however, with the more pressing matter.
CUPious exposures and potential exploitations
Our discussion target and vulnerable component is CUPS, which is a service that allows a computer to act as a print server. It is very popular, and can be found on a wide variety of Unix-like machines.
This service is very common and can certainly be a high-value target for exploitation as it tends to be exposed to other machines (and potentially the internet) by nature. Previous vulnerabilities in printing services, such as CVE-2021-34527 (PrintNightmare) or even CVE-2010-2729, have demonstrated the potential impact of this attack vector.
Even before the “official” disclosure, we theorized that CUPS was the vulnerable component. While inspecting Margaritelli’s GitHub account, we came across an interesting detail — a fork of the Apple CUPS repository from September 17, 2024 — a few days before his initial post (Figure 1).
Fig. 1: A fork of the Apple CUPS repository, made by Margaritelli a week before his post about the vulnerability
There’s also an issue on the cups-browsed GitHub that quotes Margaritelli (@evilsocket) about what is probably an aftereffect of the main vulnerability. (There’s also some choice commentary there, so bring some popcorn. 🍿)
Exploitation analysis
The attack isn’t particularly complex, but does require multiple steps to exploit successfully. Figure 2 illustrates our summary of the process, but we encourage you to read the full disclosure blog for a more thorough explanation.
Fig. 2: Successful exploitation chain
Step 1: First, the cups-browsed daemon is listening for incoming UDP connections over port 631. Its purpose is to add discovered printers to the system. An attacker that communicates with the daemon can simply coerce the victim machine to register a malicious address as a legitimate printer; that’s CVE-2024-47176.
Step 2: The next part happens while registering the malicious “printer.” As part of the registration, libcupsfilters will send an outbound request to the attacker, requesting printer attributes over the Internet Printing Protocol (IPP). As part of those attributes, printers can define specific PostScript Printer Description (PPD) files, which when used legitimately define the capabilities of the printer. This is then written to a .ppd file, unsanitized and unconstrained. That’s CVE-2024-47076 and CVE-2024-47175.
Now we have a malicious .ppd file. But how do we execute commands through it?
Step 3: Enter the cupsFilter2 directive in the PPD, which runs various filters (executable files) whenever a new print job is created. We use the filter directive to run the foomatic-rip filter, which is vulnerable to an arbitrary command injection. That’s CVE-2024-47177.
A closer look
Using Shodan, we were able to see that approximately 75,000 machines worldwide expose CUPS to the internet, in most cases using the default 631 port (Figure 3).
Fig. 3: Approximately 75,000 machines worldwide expose CUPS to the internet
The following filter can be used to query Shodan for exposed CUPS servers:
product:"CUPS (IPP)"
Additional insights
Using Akamai’s unique insights into traffic data, we saw the CUPS service running on a wide range of platforms, including Ubuntu, macOS, CentOS, Debian, Fedora, OpenShift, Oracle Linux Server, Red Hat, Rocky Linux, SUSE, openSUSE, AlmaLinux, Amazon Linux, and more.
A total of 10.1% of Linux machines in the Akamai ecosystem have port 631 (the CUPS port) open. However, only 3% of those machines regularly receive any external traffic on this port.
Although these numbers can indicate that the service is not commonly exposed externally, it’s still important for organizations to assess their own exposure and review their security policies accordingly.
Analyzing internet exposure
One of the most common ways for attackers to breach organizations is via internet-exposed services. CUPS is just one example of such a service, but the problem obviously doesn’t end there. Again using Akamai’s insights into traffic data, we assessed the exposure status of different services across thousands of organizations.
According to Akamai's data, approximately 5.4% of Linux machines are exposed to the internet and receive incoming traffic from external sources (Figure 4).
Fig. 4: Internet exposure of Linux machines
When inspecting network policies that affect this traffic, we saw that 19.3% of those machines allow incoming internet traffic by default — meaning that no specific network policies are in place to restrict or control the flow of incoming traffic.
As exposed services can easily become an attack vector, it is crucial for organizations to review and tighten their access controls.
Recommendations
As the vulnerability isn’t public yet, and there isn’t any patching timeline, the best way to prepare for this disclosure is to map out all the “friction” points in your network — whether that’s a list of all Linux machines, their internet exposure, or even CUPS use — and the segmentation policies regarding them.
Once everything is mapped, we recommend that you apply segmentation policies to limit the blast radius of any potential attack. That’s a good practice regardless of the current situation, as Linux lateral movement isn’t limited to just SSH or RCEs.
Identify CUPS use in your organization
To identify CUPS running on your machines, you can search for service and process names. From our observations, which span a variety of Unix systems and distributions, the following processes may indicate the use of CUPS:
cups-browsed (the affected process).
cupsd
cancel.cups
lpq.cups
cupsfilter
lpc.cups
lp.cups
cupsaccept
cups-lpd
lpstat.cups
lpr.cups
cupsctl
Organizations that deploy osquery can use the following queries to identify potential CUPS use on their systems (Akamai Guardicore Segmentation customers can run these queries using the Insight feature).
Detect machines listening on port 631:
SELECT pid, port, protocol, family, address, path
FROM listening_ports
WHERE port = 631
Detect running processes that might be CUPS related:
SELECT name, parent, cwd, cmdline, pid, start_time, path
FROM processes
WHERE path LIKE '%cups%'
Identify internet exposure
You can use exposure scanning services such as Shodan to identify services exposed to the internet, including CUPS.
Akamai Guardicore Segmentation customers can use the Internet Connection filter in the Reveal tab to visualize all their services and machines that receive traffic from the internet (Figure 5).
Fig. 5: The Internet Connection filter reveals all the services and machines that receive traffic from the internet
Use segmentation to limit potential blast radius
Consider the following scenario: The vulnerability is disclosed, it’s not what we expected nor prepared for, someone creates a working exploit, and a malicious threat actor uses it to breach your network.
And then what? Can they just hop to the domain controller, infect the whole network, drop their botnet/cryptominer/ransomware/trojan, and get out undetected? Or do they have to work harder, perform complex reconnaissance scans, use multiple lateral movement hops, and be more generally proactive — which would give you ample opportunity to detect the breach and react to it?
Breaches keep happening, which is why segmentation is so important. If it’s not this RCE today, then it’s another zero-day tomorrow. Flat networks are easy targets, but if we make the attacker’s life harder we could make them give up (and move to easier pastures), or force them to spend enough time and perform enough actions to slip-up, make mistakes, and be detected.
Increase your security posture in 2 steps
There are two relatively easy steps that can increase your security posture tremendously: implement a DMZ and segment your application servers.
Implement a DMZ. Servers open to the internet are inherently at higher risk; therefore, they shouldn’t have complete access to the rest of the network. Implementing a perimeter DMZ for those servers that ensures that the servers can’t access the more sensitive parts of the network makes any attacker’s life much harder.
Segment application servers. It’s usually possible to segment similar application servers together, and it might be easy to restrict their inbound and outbound traffic based on their application logic.
Take the CUPS server, for example: We know its port (UDP 631), its process (cupsd), and that it should technically only need to generate traffic to the actual printers. With that, we can create an application segment for those CUPS servers, allowing specific traffic in, and keeping most traffic out.
That way, any attacker that successfully exploits CUPS to breach the server will only be able to hop on to the printer — and a prank print job is just not that scary.
Learn more
There are other quick-win solutions that an organization can apply via segmentation to increase their security posture. Read about them in our blog post on practical segmentation.