Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
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.
- Threat actor initiates the attack
- 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.
- Victim system processes the printer attributes
- 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.
- Victim system connects to the attacker-controller IPP server
- 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.
- 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.
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demo
Laura Verheyde is a software developer at Secure Code Warrior focused on researching vulnerabilities and creating content for Missions and Coding labs.
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.
- Threat actor initiates the attack
- 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.
- Victim system processes the printer attributes
- 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.
- Victim system connects to the attacker-controller IPP server
- 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.
- 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.
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.
- Threat actor initiates the attack
- 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.
- Victim system processes the printer attributes
- 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.
- Victim system connects to the attacker-controller IPP server
- 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.
- 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.
Click on the link below and download the PDF of this resource.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demo
Laura Verheyde is a software developer at Secure Code Warrior focused on researching vulnerabilities and creating content for Missions and Coding labs.
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.
- Threat actor initiates the attack
- 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.
- Victim system processes the printer attributes
- 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.
- Victim system connects to the attacker-controller IPP server
- 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.
- 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.
Table of contents
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
The Power of OpenText Application Security + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
Secure code training topics & content
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
Resources to get you started
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
