Background
Yesterday, September 26, after significant anticipation and dramatic drum rolling on social media, a series of vulnerabilities were disclosed in the Common Unix Printing Service (CUPS), a widely used printing utility found on many Linux distributions (specifically these ones, according to the original researcher’s writeup).
These vulnerabilities are summarized below:
| CVE ID |
Severity |
Affected Service |
Description |
| CVE-2024-47176 |
8.3 |
cups-browsed <= 2.0.1 |
Binds on UDP INADDR_ANY:631 trusting any packet from any source to trigger a Get-Printer-Attributes IPP request to an attacker controlled URL. |
| CVE-2024-47076 |
8.6 |
libcupsfilters <= 2.1b1 |
cfGetPrinterAttributes5 does not validate or sanitize the IPP attributes returned from an IPP server, providing attacker controlled data to the rest of the CUPS system. |
| CVE-2024-47175 |
8.6 |
libppd <= 2.1b1 |
ppdCreatePPDFromIPP2 does not validate or sanitize the IPP attributes when writing them to a temporary PPD file, allowing the injection of attacker controlled data in the resulting PPD. |
| CVE-2024-47177 |
9.0 |
cups-filters <= 2.0.1 |
foomatic-rip allows arbitrary command execution via the FoomaticRIPCommandLine PPD parameter. |
Source: https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/#Summary
The most buzzy of these vulnerabilities is CVE-2024-47176, which affects cups-browsed. After a Red Hat security forum discussion, this was initially unofficially associated with a CVSS score of 9.9, but GitHub recently assigned it a score of 8.3 (High).
Understanding CUPS and IPP
CUPS is found on many Linux and other Unix systems for managing printing jobs and queues. It is used in conjunction with the Internet Printing Protocol (IPP) for network communication between computers and printers. IPP was designed to allow devices to discover printers and manage printing jobs over a network. Per RFC8011, this protocol runs over TCP and has been assigned port 631.
In tandem with IPP, the cups-browsed service discovers new printers on the network via broadcast, unicast (thanks to the UDP listener), and mDNS so that printers will automatically show up to clients.
This bound service is not IPP; it’s an entirely different protocol, the CUPS Browse Protocol. It should be noted that communicating over this protocol using unicast is one-way, meaning you can send data to it, but you will never receive any data back. This fact makes scanning for such a service nearly impossible since there is no return data, and it runs over UDP, and more often than not, ICMP port unreachable messages (which is how some scanners determine if there is a remote UDP service listening) are filtered at the edge or on the host.
The first CVE in the chain is CVE-2024-47176, which states that the cups-browsed service binds on INADDR_ANY (meaning it binds to all network interfaces) on UDP port 631. This basically allows any remote user to communicate with the underlying service.
A malicious user could send a specially crafted packet that informs this “browsed” server that there is an IPP (TCP) printer located on the internet. The process then attempts to connect to that remote server (using IPP via TCP); once established, that malicious server could send back a set of configurations and PostScript Printer Descriptions (PPD) that can trigger the victim server to execute arbitrary commands after a print job has been enqueued.
NOTE: This exploit requires the victim to manually select and use the malicious print server.
This does not matter for the servers that do not run or expose CUPS publicly. However, if a host exposes an affected CUPS service to the public Internet, a remote threat actor can send a malicious UDP packet to port 631 without needing authentication, which will then trigger the CUPS service to connect back to a malicious server over TCP.
Additionally, the same server injection can be done over mDNS if CUPS has been configured to do so.
What Should You Worry About?
Factors that mitigate the risk:
- If CUPS was unintentionally installed on a server but is never actually used for printing, then it’s unlikely that this has any direct impact, as it requires a person to send a print job to the malicious print queue. However, if you think you may have been affected, running the command lpstat -a will list all of the known printers on the local hots. If any of the entries look strange or suspicious, someone has most likely targeted your server. Do not attempt to print to that suspicious server.
- This exploit requires user interaction (a print job to the malicious printer must be triggered) to lead to RCE. Given this fact, it is more likely that this vulnerability would be used to move laterally within a network:
- The attacker injects a malicious print server
- Attacker runs $ echo nop | lpr -P $MALICIOUS_PRINTER_NAME
Factors that emphasize the risk:
Censys Perspective
Censys data reveals that there are 63,096 exposed CUPS IPP services running on the public internet. Note that you cannot determine if the Browse Protocol is running unless you send the actual exploit and have the service connect back over TCP.
Of these, 7,289 show indications of running a version affected by these CVEs (versions = 2.0.1). Note that different scanners count affected services differently. For the purposes of this post, we are treating TCP/631 (IPP) as a proxy for potential UDP/631 exposure.
Map of Publicly Exposed CUPS services running a version <= 2.0.1.
Note that not all of these services are necessarily running the affected cups-browsed daemon, and again, a print job must be triggered on the target machine to the malicious printer in order for the exploit to succeed.
| Country |
Host Count |
| United States |
2230 |
| South Korea |
567 |
| Taiwan |
522 |
| France |
343 |
| Germany |
207 |
| Japan |
204 |
| Italy |
183 |
| Hong Kong |
178 |
| United Kingdom |
174 |
| Poland |
172 |
What Can Be Done?
Exposing a CUPS service to the public internet is ill-advised unless absolutely necessary for operation. There are no patches available yet for this vulnerability, so in the interim it’s recommended to disable the cups-browsed service by running the following commands on your server:
systemctl stop cups-browsed
systemctl disable cups-browsed
In addition it’s recommended to block traffic to 631/UDP – although note that this doesn’t mitigate the risk of local network exploitation via mDNS or the other channels mentioned above.
References
