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
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
The Secure-by-Design movement is the future of secure software development. Learn about the key elements companies need to keep in mind when they think about a Secure-by-Design initiative.
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
.png)
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.
The Benefits of Benchmarking Security Skills for Developers
The growing focus on secure code and Secure-by-Design principles requires developers to be trained in cybersecurity from the start of the SDLC, with tools like Secure Code Warrior’s Trust Score helping measure and improve their progress.
Driving Meaningful Success for Enterprise Secure-by-Design Initiatives
Our latest research paper, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise is the result of deep analysis of real Secure-by-Design initiatives at the enterprise level, and deriving best practice approaches based on data-driven findings.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
