CUPS Vulnerability: What You Need to Know

The CUPS Conundrum: A Perfect Storm of Vulnerabilities

Picture this: four seemingly innocuous vulnerabilities that, when chained together, create a perfect storm for remote code execution on Linux and Unix systems. That’s exactly what we’re facing with the latest CUPS vulnerability.

These vulnerabilities, identified as CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177, affect various components of the CUPS ecosystem, including cups-browsed, libcupsfilters, libppd, and cups-filters. Below is a list of these components and their affected versions:

CVE-2024-47176
- cups-browsed <= 2.0.1
CVE-2024-47076
- libcupsfilters <= 2.1b1
CVE-2024-47175
- libppd <= 2.1b1
CVE-2024-47177
- cups-filters <= 2.0.1

Common Linux vendors have also released their own advisories regarding the individual CUPS component’s vulnerabilities:

Canonical (USN-7041-1)
- Recommendation: Disable cups-browsed service and update affected packages immediately.
Red Hat (RHSB-2024-002)
- Recommendation: Disable cups-browsed service if not required, apply security patches.
SUSE (SUSE-SU-2024:3570-1)
- Recommendation: Update CUPS installations, apply security patches, disable cups-browsed service.
Oracle (ELSA-2024-7346)
- Recommendation: Limit network access, disable nonessential services, assess exposure risks.

The criticality of the CUPS vulnerability is a result of these several individual vulnerabilities. It’s uncommon to successfully chain many vulnerabilities together, however the code issues leading to these vulnerabilities are tightly coupled.

The only thing stopping these exploits from being a full-on remote takeover is that a user has to print from the malicious printer that the attacker creates on their machine. However, as we will see in the screenshots below, we can create printers that look extremely innocent and would be very easy to accidentally print from in an office environment.

The Attack Vector: A UDP Packet’s Journey to Mayhem

Here’s where it gets interesting. The attack vector starts with a simple UDP packet sent to port 631, the default port for the cups-browsed service. On vulnerable systems, this innocent-looking packet can be the key to replacing existing printers or installing new malicious ones.

This can all happen silently, without alerting the system’s users or administrators. Once the malicious printer is in place, it’s just a matter of time before someone starts a print job, unknowingly executing arbitrary commands on the compromised system.

There are several repositories on GitHub that can be used to scan for the CUPS vulnerability, and to check if a system is vulnerable. IppSec’s GitHub repository PoC is the closest to a weaponized exploit from what we can find. While this exploit chain requires user interaction, it’s still considered high severity due to its simplicity and availability.

At a high level, below is an image of the chain of events that triggers the malicious code to run.

cups_overview1 | Atvik Security — High level overview of the exploit path

In more detail, the following steps occur:

The attacker sends a UDP (631) packet to the victim that includes a malicious IPP server URL. This packet is meant to indicate that there is a new printer on the network.
The victim sends a POST request (a Get-Printer-Attributes request from CUPS) to gather new information about this new printer. This request is sent to the malicious IPP server.
With this newly gathered information from the IPP server, the victim’s CUPS server creates a PostScript Printer Description (PPD). The PPD is used to describe the printer and what features it supports.
CUPS reads the configuration from the attacker’s IPP server, to create the PPD file with. There is a bug in the FoomaticRIPCommandLine directive that allows any value specified to be executed as a command.
The victim then has to send a print job to the malicious IPP server (print to the malicious printer). Once the print job is sent, the arbitrary command specified in the PPD file is executed.

Atvik Security’s Research and Recreation

Atvik Security also utilized the CUPS vulnerability and exploit within our own lab environment. Below are our findings from recreating the vulnerability and exploits.

First, we performed a cursory Google search regarding Proof of Concept (PoC) code for the recent CUPS vulnerability. We originally landed on the Gist that contains the original report, and saw the CUPS GitHub Security Advisory (GHSA) that includes some PoC. Both of the files don’t work as-is and require some modifications, but with both files, an attacker is still able to piece together a single working PoC.

We found that in the original Gist and GitHub Security Advisory (GHSA) the printer-privacy-policy-uri was used to store the arbitrary commands. However, this attribute did not trigger the command to be executed. We reviewed the IPP specification in search of a more commonly used attribute. It’s important that the exploit uses a printer attribute that is commonly used by the victim’s machine, so that the exploit is reliable.

image | Atvik Security — printer more info attribute in the IPP specification

So we settled on swapping printer-privacy-policy-uri to printer-more-info.

After combining the two PoCs publicly available and changing the printer attribute that the command is stored in, the exploit then worked as expected. However, we instead settled on using IppSec’s repository which included quite a few other reliability modifications.

Our environment is as follows:

Victim: 192.168.8.2 running unpatched Linux Mint 21.3
Attacker: 192.168.199.196

With the lab environment laid out we cloned IppSec’s repository, installed its dependencies, and then ran the exploit to add the malicious printer to the victim’s machine. We used the following commands:

git clone https://github.com/ippsec/evil-cups
cd evil-cups
pip install -r requirements.txt
python exploit.py 192.168.199.196 192.168.8.2 "echo 1 > /tmp/I_AM_VULNERABLE1"

As the victim, we navigated to our machine’s “Printer” app, selected the printer, and printed a test page.

Upon pressing “Print Test Page”, we see that the job was successfully submitted, and that it’s processing.

The victim’s machine presents a “print error”, but at this point the attacker’s malicious code has already executed.

print_error_1 | Atvik Security — Print Error occurs ~30 seconds after waiting for the test page to print

In the command that we used to execute exploit.py, we also specified a command that we wanted the victim to run ("echo 1 > /tmp/I_AM_VULNERABLE1"). We can see on the victim’s machine that a file was created at /tmp/I_AM_VULNERABLE1 by the Linux user and group lp. This exploit could also be weaponized to get a reverse shell, allowing an attacker full interactive command line access to the victim.

Atvik Security also captured network traffic between the attacking machine and the victim. From these IPP protocol packets, we can see the printer attributes that are being sent from the malicious IPP server to the victim. Within these attributes, we can see our malicious command being included in the printer-more-info attribute.

Mitigation Strategies: What Can We Do?

As of this post, additional patch hardening is being performed on the various CUPS components. However, the latest versions of the libraries are no longer vulnerable to the above vulnerabilities. As a result, there are several mitigation strategies we can recommend to our clients:

Disable cups-browsed: If the service isn’t necessary, disabling and removing it is the most straightforward mitigation.
Network restrictions: Blocking or restricting traffic to UDP port 631 can significantly reduce the attack vector. In most cloud environments, all incoming traffic is implicitly denied, however you will still want to review any open ports in your cloud environment (especially cloud workstations / thick clients).
Update the components (cups-browsed, libcupsfilters, libppd, and cups-filters) to their latest versions, using your package manager (apt, yum, etc.).

Conclusion: Stay Informed, Stay Secure

Keep an eye out for patch releases, continue to monitor for any signs of exploitation, and don’t hesitate to reach out to the broader security community for insights and support. After all, in the world of cybersecurity, we’re stronger together.