Blog

Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems

October 7, 2024
Laura Verheyde

Linux users haven’t had an easy time lately, with several high-severity vulnerabilities reportedly affecting the system in various ways over the past few years. Security researchers now have another cluster of vulnerabilities to unpack, all relating to the Common UNIX Printing System (CUPS) function targeting GNU/Linux systems with a potential pathway for potent Remote Code Execution (RCE).

On September 27, 2024, evilsocket.net’s Simone Margaritelli published critical information about several exploitable vulnerabilities in CUPS, with CVEs subsequently assigned to four of them. This number could grow, but at the time of writing, the security community is debating the actual severity of these discoveries. While one of the CVEs, CVE-2024-47177, has a current critical severity rating of 9.1 from MITRE, successful manipulation of this command injection flaw is reliant on servers with the CUPS service enabled and, additionally, requires access to UDP port 631 or DNS-SD. RedHat notes, however, that it is possible to remap CUPS to a different port. 

Margaritelli’s comprehensive breakdown of the incident reveals an insidious, complex chain of attacks that, despite community disagreements, should not be ignored. It affords us a lesson on seemingly innocuous dependencies being deeply exploitable if a threat actor is determined enough and if small windows of opportunity have been left open by poor coding patterns.

The CUPS scenario is a little different from what many developers and AppSec professionals may have previously experienced, so let’s take a look and test your skills along the way.

The vulnerability: Remote Code Execution (RCE) Via CUPS

The Evilsocket blog provides an unmatched, thorough background to these exploits, and this is a resource we will continue to follow closely. Margaritelli also quotes an unnamed source in his article, who does not appear optimistic about the general security robustness of Linux:



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.

This is a sobering reminder of the inherent security risks that remain prevalent in open-source environments, not to mention the dire need for heightened security awareness and secure coding skills among the global development community.

Let’s take a look at the CVEs:

The vulnerability chain is widespread, and currently impacts all current and previous versions of the following packages:

  • distrotech/cups-filters
  • OpenPrinting/cups-filters
  • Cups-browsed
  • libcupsfilters
  • libppd

CUPS has been a legacy component of UNIX and Linux operating systems for over two decades. Its function as a print services dependency makes it eager to perform network requests, rendering it a prime target for RCE-class vulnerabilities.

In this instance, however, there is some ingenuity in how the attacks combine to provide a successful outcome. This is essentially the ability of an unauthenticated, undetected attacker to replace Internet Printing Protocol (IPP) URLs with malicious ones, in addition to modifying directives that can cause command injection in the "PPD (PostScript Printer Description) file, which is a file used to describe the features of the newly added printer. This results in a command execution attack once a print job is activated, and relies on a lack of input validation within the CUPS components.

Further, fixing this particular vulnerability creates something of a double-edged sword, as Evilsocket points out. CUPS includes the foomatic-rip filter, an executable with prior history of being a high-risk, exploitable component. CVEs relating to this component date back to 2011, and while it has been established that foomatic-rip can be leveraged to execute OS commands, fixing this causes stability issues and loss of support for many older printers. It is a complex problem to overcome.

  1. Threat actor initiates the attack
    1. CVE-2024-47176: cups-browsed <= 2.0.1 is vulnerable because it binds to UDP port 631 using INADDR_ANY, which means it trusts any packet received from any source. This allows an unauthenticated remote attacker to send a malicious UDP packet with a manipulated IPP URL (pointing to the attacker-controlled IPP server), triggering the vulnerability. The victim’s machine now thinks it’s connecting to a new printer and sends a request asking for printer attributes.
  2. Victim system processes the printer attributes
    1. CVE-2024-47076: libcupsfilters <= 2.1b1 has a vulnerability in cfGetPrinterAttributes5, which does not properly validate or sanitize the IPP attributes returned from an IPP server. When cups-browsed processes the packet, it can be tricked into reading malicious attributes sent by the attacker.
  3. Victim system connects to the attacker-controller IPP server
    1. CVE-2024-47175: libppd <= 2.1b1 in the ppdCreatePPDFromIPP2 function does not properly validate or sanitize IPP attributes when saving them to a temporary PPD (PostScript Printer Description) file. This allows the attacker to inject arbitrary data into a PPD file, including the FoomaticRIPCommandLine directive, which the printing system can later execute.
  4. Victim system initiates print job and attacker’s code is executed
    CVE-2024-47177
    : cups-filters <= 2.0.1 is vulnerable because the foomatic-rip filter executes arbitrary commands through the FoomaticRIPCommandLine directive, allowing the attacker to run commands as the cups-browsed process. The attacker waits for the victim’s machine to initiate a print job. The moment this happens, the attacker’s malicious code will be executed (Remote Code Execution).

How can you mitigate RCE risk?

For companies utilizing CUPS as part of their business operations, they must follow the recommended remediation advice from Evilsocket and RedHat. This includes, but is not limited to, applying security patches as an emergency-level priority.

For Command Injection in general, check out our comprehensive guide.

If you’re interested in getting more free coding guidelines, check out Secure Code Coach to help you stay on top of secure coding best practices.

Govern AI-driven development before it ships

Measure AI-assisted risk, enforce secure coding policy at commit, and accelerate secure delivery across your SDLC.

book a demo
Slogan

Dies ist eine dynamische Überschrift mit Tag- und Stiloptionen

Lorem ipsum diam quis enim lobortis scelerisque fermentum dui faucibus in ornare quam viverra orci sagittis eu volutpat odio facilisis.

browse all
Case Study
Filter Label

Supercharged Security Awareness: How Tournaments are Inspiring Developers at Erste Group

Learn More
Case Study
Filter Label

Security as culture: How Blue Prism cultivates world-class secure developers

Learn how Blue Prism, the global leader in intelligent automation for the enterprise, used Secure Code Warrior's agile learning platform to create a security-first culture with their developers, achieve their business goals, and ship secure code at speed

Learn More
Case Study
Filter Label

One Culture of Security: How Sage built their security champions program with agile secure code learning

Discover how Sage enhanced security with a flexible, relationship-focused approach, creating 200+ security champions and achieving measurable risk reduction.

Learn More

Secure AI-driven development before it ships

See developer risk, enforce policy, and prevent vulnerabilities across your software development lifecycle.

book a demo