Skip to content

Search the site

Critical 9.9 Linux bug: CUPS your ears, the details are here!

Some 300,000 endpoints may be publicly exposed to RCE, but these are likely to be largely desktops not servers.

Image credit: Bank Phrom, via Unsplash.com

Updated Friday September 26, 10.00 BST with comment from CUPS' creator.

Details of several critical Linux vulnerabilities that the security community has been awaiting have landed – they involve bugs in CUPS, the Common UNIX Printing System. All versions of Red Hat Enterprise Linux (RHEL) are among the Linux distributions affected, but not in default configuration. 

Detail on other impacted distributions continues to land, but default exposure does not appear to be likely and risk moderate as a result.

The vulnerabilities (four identified and allocated CVE-2024-47076, CVE-2024-47175, CVE-2024-47176 and CVE-2024-47177, with more to follow) were identified by security researcher Simone Margaritelli, who first posted about them vociferously on X on September 23. 

Margaritelli suggested that up to 300,000 endpoints may be publicly exposed to pre-authentication remote code execution exploitation. (Security researchers suggested that the majority of these are likely to be desktops, not servers. Qualys analysis shows 75,000 publicly exposed assets. A huge majority of these assets were found on the default IPP port 631. Over 42,000 of these accept unauthenticated connections.)

The vulnerability details were leaked this evening by Michael R Sweet, the creator of CUPS, the de-facto standard printing system for Linux, macOS, and UNIX systems via a bug fix on GitHub; apparently breaking plans for coordinated disclosure on September 30, then a public blog on October 6. 

See also: CUPS Creator – Fixes coming soon

Margaritelli, aka evilsocket, subsequently published his write-up

In terms of who is affected, he said in it: "This thing [CUPS] is packaged for anything, in some cases it’s enabled by default, in others it’s not, go figure."

When it comes to exploitation, Margaritelli, in short, found that if the cups-browsed daemon is enabled it will listen on UDP port 631 and then by default (it is NOT enabled by default) allow remote connections from any device on the network to create a new printer. An attacker can then create a malicious printer server – and if they trick a user into using it on their local network, exploit away...

Sonatype field CTO Illka Turunen commented: "It's an RCE but with several mitigations, including the fact the attacker needs to be able to connect to a computer via UDP which is widely disabled on network ingress and the service is usually not on by default. It seems like the real world impact is low..."

CUPS creator Michael Sweet told The Stack: "We have been working on fixes for the last three weeks and hope to have them available soon. We are removing support for the old CUPS browse protocol completely - it was never intended for use on the Internet, has both security and performance issues on local networks, and hasn't been needed since CUPS 1.5. The PPD generation code in libcupsfilters and libppd is being updated to validate all of the values returned by a printer and ensure that no extra content gets included in the PPD file."

Critical CUPS vulnerability: Chain for RCE

Margaritrelli said the vulnerabilities could be summarised as follows.

CVE-2024-47176 | 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 | 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 | 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 | cups-filters <= 2.0.1 foomatic-rip allows arbitrary command execution via the FoomaticRIPCommandLine PPD parameter.

Red Hat said that "mitigation of these vulnerabilities is as simple as running two commands, especially in any environment where printing is not needed." For RHEL, it added, “exploitation of these vulnerabilities is possible through the following chain of events:

  1. The cups-browsed service has manually been enabled or started
  2. An attacker has access to a vulnerable server, which :
    1. Allows unrestricted access, such as the public internet, or
    2. Gains access to an internal network where local connections are trusted
  3. Attacker advertises a malicious IPP server, thereby provisioning a malicious printer
  4. A potential victim attempts to print from the malicious device
  5. Attacker executes arbitrary code on victim’s machine

By chaining the vulnerabilities a remote attacker can hit endpoints via “WAN / public internet: a remote attacker sends an UDP packet to port 631. No authentication whatsoever” security researcher Margaritelli added; another vector is LAN, where “a local attacker can spoof zeroconf / mDNS / DNS-SD advertisements… and achieve the same code path leading to RCE.”

Attack surface management firm WatchTowr’s founder Benjamin Harris, whose team caught the leak early, told The Stack via DM that "the CUPS daemon and associated packages is the most widely-used way to manage printing and print services on Linux Desktop editions (think Ubuntu Desktop, in contrast to the commonly used server edition Ubuntu Server)...while the technical impact of the vulnerabilities is serious… these vulnerabilities are unlikely to be the watershed moment that MS08-067, EternalBlue, and HeartBleed were (that these vulnerabilities have been compared to."

Matthiew Morin, of security firm, NetRise, noted: "From a remediation perspective, it's pretty 'simple'. The problem is that it's installed on pretty much every Linux system by default. So it's not a question of 'is there a good reason to have this type of config?' It's a statement that by default many of these systems have this configuration and the operators of the device likely do not know it.There are likely a bunch of XIoT devices affected and as we've seen here at NetRise, we know that operators of these devices have no idea what software is running on them let alone being able to manage and secure these devices.
Again, luckily the remediation for this is fairly easy. As the article points out:

  • Disable and remove the cups-browsed service if you don’t need it (and probably you don’t).
  • Update the CUPS package on your systems.
  • In case your system can’t be updated and for some reason you rely on this service, block all traffic to UDP port 631 and possibly all DNS-SD traffic (good luck if you use zeroconf)" he added.

More detail and reaction to follow early Friday, BST.

(For those receiving this by email, this story will be updated on our website.)

Views? Pop us a line.

Latest