CUPS Vulnerability Response Resources

Resources and analysis on the latest zero days: CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177

Four CVEs related to the CUPS vulnerability have been released, CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177. The quick summary is to take a breath: it’s not a global meltdown, but you should still check if your cups service is running. Section one is technical details for responders, section two is industry analysis.

TL;DR for responders:

1. CUPS (Common Unix Printing System) is a Linux package used for managing printers. It does both basic add/remove functionalities, job queues, network printing, and most importantly, hosts an interface on port 631

2. Here’s how an attacker would exploit the vulnerability:

   

   1. Access the print service and setup a fake printer using IPP (Internet Printing Protocol) on port 631

   2. Point the new printer to an attacker controlled URL

   3. Use that data to craft a malicious PPD (PostScript Printer Description) File

   4. This malicious file can trigger a buffer overflow into a remote code execution as root (which is a worse case scenario and why it’s a 10)

3. What to check first:

   1. Most server distros do not have CUPS installed or enabled by default. I’ve personally checked Ubuntu doesn’t have it installed.

   2. The attack requires network access to 631, shutting this off from the internet is the easiest immediate solution.

   3. Most desktop Linux distros have CUPS installed and enabled by default. These would be the biggest risk, but they’re also not usually open to traffic from the internet or heavily processing sensitive data.

   4. It’s worth checking your network logs to threat hunt on port 631, it would potentially be a good way to see if anyone’s in your network already.

Commands for checking vulnerability exposure:

Check if related services are running:

systemctl status cups-browsed
systemctl status cups

Check if anything is listening on port 631:

sudo netstat -anu | grep ":631"
sudo lsof -i UDP:631

Disabling and uninstalling cups (this also would need to be done for cups-browsed:

sudo systemctl stop cups
sudo systemctl disable cups
sudo apt remove cups

Blocking 631 with ufw (Uncomplicated Firewall) or iptables:

sudo ufw deny 631/tcp
sudo ufw deny 631/udp
sudo iptables -A INPUT -p tcp --dport 631 -j DROP
sudo iptables -A INPUT -p udp --dport 631 -j DROP

What about mDNS?

mDNS is how local networks discover other local devices - for example how your phone knows a chromecast is listening for connection. Similarly, mDNS is used for printer discovery in CUPS. Some articles recommend turning this off as well, but I think it’s really debatable - there are some hypothetical exploits where attackers can spoof other devices, but I view this as a separate attack vector not really related to this CVE. To be clear, you can still turn it off, and it’s definitely safer to do so, but you’re more likely to break IoT devices in the process if you’re using Linux desktops. In general, it’s worth investigating if you should turn this off.

The Vulnerability’s not done

The drama around this vulnerability continues to unfold, and the next key finding will be if MacOS is effected. This is hinted at here by evilsocket (the researcher, Simone Margaritelli) as well as in the article, but it’s still unclear. My guess would be that it’s in the disclosure process with Apple, but now that the cat’s out of the bag this will be a huge area of focus for research.

If you’re wanting to be proactive, blocking mDNS at the firewall is probably a good step, but again it’s likely to break some end user things (UDP: 5353).

What this Means for the Industry

Now that the important responder info is out there, let’s pontificate on the drama around this.

First, evilsocket laments the pain of the disclosure process. Without getting into the details of the drama, he’s right that there is zero process or control of how this stuff happens in open source. The expectations the industry places on both researchers and maintainers is too high. The key problem to me is a lack of process and escalation for reporting and disclosures within open source more than any particular arguments between developers. On the one hand, security disclosures need to be acted on with more focus. On the other hand, there are a lot of people turning minor bugs into major security issues.

Second, a key observation, likely out of frustration, evilsocket also says “it is also the last time” he attempts to disclose a vulnerability. Whether or not that’s true, it speaks to the fact that we rely way too much on CVEs as a detection mechanism, when they’re a hardening mechanism. Increasingly, complicated Linux and container attacks will not be reported in a timely way, whether due to complexities or the NVD backlog, making vulnerability management a worse and worse long term strategy.

Finally, based on these conclusions, I continue to think that runtime application, container, and cloud solutions provide far more value then their scanning alternatives. We need more modern solutions for detecting zero day exploits than old school malware detectors. Of all the vendors out there, I have the most confidence that Oligo Security would have caught this exploit due to the deviation from the package profile. Other vendors who I think would have caught this are Raven.io (package deviation based), Sweet Security (anomaly based), ARMO (anomaly based), Upwind (outbound network to attacker), and Rad (anomaly based, but I don’t know if non-container environments are supported). I have less confidence but would need to test if Aqua and Sysdig would catch this.

Overall, we have yet another potentially massive security issue that’s mostly mitigated due to the hard work of both vulnerability researchers and maintainers, and it’s a better world if they’re not having to fight in the process.