Fixing the RCE flaw in the Common Unix Printing System (CUPS)

Several vulnerabilities have been identified in the Common Unix Printing System (CUPS), impacting multiple UNIX-based operating systems, including Linux and macOS. The flaw can be triggered by sending a maliciously crafted HTTP request to the CUPS service, potentially allowing an attacker to remotely access and control affected systems.

What are the Common UNIX Printing System RCE bugs?

A severe security flaw has been discovered, affecting every GNU/Linux system and possibly extending to other platforms. Unveiled by security researcher Simone Margaritelli, the flaw is the result of chaining several vulnerabilities which, combined together, enable remote code execution (RCE) without authentication. 

Known as @evilsocket, security researcher Simone Margaritelli was the one to uncover this chain of critical vulnerabilities in the CUPS (Common Unix Printing System) utilities, specifically in components like cups-browsed, libcupsfilters, and libppd. 

Identified as CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177 – the bugs affect widely adopted UNIX systems such as GNU/Linux, BSDs, ChromeOS, and Solaris, exposing them to remote code execution (RCE). 

Both Canonical and Red Hat have verified the threat, assigning it an alarmingly high CVSS score of 9.9 out of 10, highlighting its critical nature. Cybersecuritynews reports that this vulnerability, which has persisted for more than a decade, will be fully revealed in under two weeks, following an agreement with the developers. 

By exploiting this vulnerability, attackers could execute arbitrary code on the target machine, and in some cases, even escalate their privileges, giving them greater control over the compromised system. The wide adoption of CUPS across various platforms makes this a significant security concern for organizations relying on UNIX-based systems. 

While both Canonical and Red Hat have recognized the severity of the vulnerability and are in the process of evaluating its scope and developing patches, internal disagreements among some developers about the vulnerability’s true impact may be contributing to delays in rolling out fixes. All versions of Red Hat Enterprise Linux (RHEL) are affected but are not vulnerable in their default configurations. 

How do attacks in UNIX systems via CUPS affect me?

CUPS and specifically cups-browsed are packaged for most UNIX systems: most GNU/Linux distributions, some BSDs, Google Chromium / ChromeOS, Oracle Solaris and possibly more. In his in-depth analysis, Margaritelli showcases in full detail a step by step flow of the Attacking of UNIX Systems via CUPS. 

He demonstrates how the flaw, among others, is related to a filter called foomatic-rip, a well-known issue (confirmed by the CUPS devs) which turns out hasn’t been fixed for decades. According to him, the only reason not to consider the existence of something that allows arbitrary commands in a generally untrusted context as a security issue worth fixing, is due to the simple fact that it’s extremely difficult to fix. 

CUPS developers statement noted: “It is very difficult to limit what can be provided in the FoomaticRIPCommandLine line in the PPD file.”. They then added: ‘REDACTED’ and the rest of the OpenPrinting team have been talking about ways to limit what can be done through Foomatic without breaking existing drivers – we can certainly recommend that people not use Foomatic, but there are likely hundreds of older printer models (before 2010) that are only supported through Foomatic.” 

Timeline to full vulnerability disclosure

With the initial disclosure by Margaritelli being made weeks ago, detailed information remains withheld to give developers time to respond. However, a working fix has yet to be released. 

After several discussions, Margaritelli and the developers set the following disclosure schedule: 

• On September 30 –  Initial report will be shared with the Openwall security mailing list 
• On October 6 –  Full technical details of the vulnerability will be made public. 

Interestingly, there has also been a notable delay in assigning CVE IDs for this issue. Margaritelli speculated that the vulnerability’s complexity may have required assigning anywhere from three to six CVEs, with eventually a chain of 4 CVEs have been associated to this vulnerability. 

According to some reports, Margaritelli has voiced his frustration with the vulnerability disclosure process. After dedicating three weeks of sabbatical time to this issue, he described facing resistance from developers who were reluctant to acknowledge flaws in their code. 

Meanwhile, the lack of specific technical details has left users and security professionals on edge. Without knowing the precise components or versions affected, organizations are finding it difficult to take preventative actions. 

Adding to the complexity, the absence of assigned CVEs raises concerns about how effectively communication is being handled between the researcher, vendors, and organizations responsible for managing vulnerability databases. 

Despite presenting several proof-of-concept (PoC) examples that countered developers’ assumptions, progress has been slow. This situation underscores the importance of responsibly handling vulnerability disclosures. It also highlights how things can go wrong when there isn’t effective collaboration between researchers and developers. 

According to The Stack’s report, Some 300,000 endpoints may be publicly exposed to RCE (likely to be largely desktops not servers) They also state that the vulnerability details were leaked by Michael R Sweet, the creator of CUPS, the de-facto standard printing system for Linux, macOS, and UNIX systems via a bug fix on GitHub; apparently breaking plans for coordinated disclosure on September 30, then a public blog on October 6.  

Simone Margaritelli outlines the vulnerabilities affecting CUPS as follows: 

Red Hat emphasized that “mitigating these vulnerabilities is straightforward and can be accomplished with just two commands, particularly in environments where printing is unnecessary.” For Red Hat Enterprise Linux (RHEL), they outlined the possible exploitation sequence as follows: 

1. The cups-browsed service has been enabled or activated manually. 
2. An attacker gains access to a vulnerable server, which: 
   1. Provides unrestricted access, such as over the public internet, or 
   2. Allows access within an internal network where local connections are trusted. 
3. The attacker advertises a malicious IPP server, effectively provisioning a malicious printer. 
4. A potential victim attempts to print using this compromised device. 
5. The attacker executes arbitrary code on the victim’s system. 

By leveraging these vulnerabilities, a remote attacker can target endpoints over the public internet. Margaritelli notes, “A remote attacker can send a UDP packet to port 631 without any authentication.” Additionally, local attackers can spoof zeroconf, mDNS, or DNS-SD advertisements to achieve the same exploitation pathway leading to RCE. 

Benjamin Harris, founder of the attack surface management firm WatchTowr, shared with The Stack that “the CUPS daemon and related packages are the most commonly used method for managing printing and print services on Linux desktop distributions (like Ubuntu Desktop), as opposed to the widely utilized server version, Ubuntu Server). While the technical implications of these vulnerabilities are severe, they are unlikely to reach the same level of notoriety as incidents such as MS08-067, EternalBlue, or Heartbleed.” 

How to address the critical remote code execution vulnerability in CUPS on UNIX-based systems

While Margaritelli acknowledges the difficulties developers face, he emphasizes the need for prompt action in addressing vulnerabilities. He also praised Canonical for their ongoing mediation efforts since the initial stages. A file collated by him contains a list of the Linux versions affected. He also recently mentioned: “This thing is packaged for anything, in some cases it’s enabled by default, in others it’s not, go figure.” 

To mitigate the Remote Code Execution (RCE) vulnerability in CUPS, take the following immediate actions: 

1. Disable or Restrict the CUPS Service: If updating the system is not an option, consider disabling the CUPS service or limiting access to its web interface. Blocking all traffic to UDP port 631 and, where applicable, DNS-SD traffic (excluding zeroconf) can prevent exploitation while allowing limited functionality. 
2. Strengthen Security with Network Segmentation and Access Controls: By segmenting your network and enforcing strict access controls, you can reduce the scope of the vulnerability and limit the potential for lateral movement within the network. 
3. Perform Comprehensive Vulnerability Scans and Penetration Testing: Regularly assess your systems for security gaps by conducting vulnerability scans and penetration tests. Identifying and patching other possible vulnerabilities will strengthen your overall security posture. 
4. Enhance Incident Response and Disaster Recovery Plans: Prepare for a worst-case scenario by ensuring your incident response and recovery strategies are well-established. This will help minimize the damage in the event of a breach. 
5. Keep an eye on updates from trusted security sources and official vendor announcements and be prepared to deploy patches as soon as they are available to mitigate the threat effectively. 

With full disclosure approaching rapidly, the pressure to act grows stronger. The global Linux community and its users are eagerly awaiting patches to protect their systems against this critical flaw.  

Nevertheless, important to note also that despite the 9.9 CVSS score indicating extreme severity, it’s recommended to remain cautious. High scores don’t always mean vulnerabilities are easy to exploit in real-world conditions. A case in point, CVE-2024-7589, an SSH vulnerability was initially rated at 9.8 but was later downgraded to 8.1 due to the challenges involved in exploiting it. 

Further reading

Each new vulnerability is a reminder of where we stand and what we need to do better. Check out the following resources to help you maintain cyber hygiene and stay ahead of the threat actors: 

1. Q3 2024 Vulnerability Watch
2. The MITRE ATT&CK framework: Getting started
3. The true impact of exploitable vulnerabilities for 2024
4. Vulnerability disclosure policy (and how to get it right)
5. How to properly tackle zero-day threats