Critical Linux bug is CUPS-based remote-code execution hole

Final update After days of anticipation, what was billed as one or more critical unauthenticated remote-code execution vulnerabilities in all Linux systems was today finally revealed.

In short, if you’re running the Unix printing system CUPS, with cups-browsed present and enabled, you may be vulnerable to attacks that could lead to your computer being commandeered over the network or internet. The attacks require the victim to start a print job. Do not be afraid.

The bugs were found and privately reported by software developer Simone Margaritelli who has now openly disclosed the security weaknesses in detail here. This write-up is said to be part one of two or maybe three, so expect more info at some point.

He went public today at 2000 UTC after seemingly becoming frustrated with the handling of his vulnerability reports by CUPS developers. No patches are available yet. Public disclosure was previously expected to be no later than September 30.

What you need to know for now, according to Margaritelli, is:

• Disable and/or remove the cups-browsed service.
• Update your CUPS installation to bring in security updates if or when available.
• Block access to UDP port 631 and consider blocking off DNS-SD, too.
• It affects “most” Linux distros, “some” BSDs, possibly Google ChromeOS, Oracle’s Solaris, and potentially others, as CUPS is bundled with various distributions to provide printing functionality.
• To exploit this across the internet or LAN, a miscreant needs to reach your CUPS service on UDP port 631. Hopefully none of you have that facing the public internet. The miscreant also has to wait for you to start a print job.
• If port 631 isn’t directly reachable, an attacker may be able to spoof zeroconf, mDNS, or DNS-SD advertisements to achieve exploitation. Details of that path will be disclosed later, we’re promised.

If you don’t have cups-browsed on your system, you’re good. If you don’t need CUPS, consider removing it all from your computer just to be safe. If you never print anything, you’re probably also good.

How would a vulnerable system be hijacked? “A remote unauthenticated attacker can silently replace existing printers’ (or install new ones) IPP URLs with a malicious one, resulting in arbitrary command execution (on the computer) when a print job is started (from that computer),” says Margaritelli.

Two libraries, one CUPS

Breaking it down further, here are the four bugs Margaritelli has so far publicly documented:

1. CVE-2024-47176 in cups-browsed up to version 2.0.1. This listens on UDP port 631, trusts “any packet from any source,” and will use that data to fire off an IPP request to an attacker-controlled URL.
2. CVE-2024-47076 in libcupsfilters up to version 2.1b1. This does not validate the attributes returned by that above IPP request, allowing an attacker to pipe malicious data into the victim’s CUPS system.
3. CVE-2024-47175 in libppd. This also does not validate those IPP attributes when writing them to a temporary PPD file.
4. CVE-2024-47177 in cups-filters up to version 2.0.1. This will execute arbitrary commands from data in a PPD file.

Chaining those together, you can send a packet to UDP port 631 on a target vulnerable machine, make that computer reach out to a server you control, have that server feed a payload of commands as data to the target to then write to a PPD temporary file, and then when the user starts a print job, it triggers execution of those commands from that file.

Neat, and we can see how this might, just might, ruin an office or lab worker’s day, but it’s overall not Earth shattering. Margaritelli has confirmed user interaction by the victim is required (they need to start a print job) and has hinted that a buffer overflow might be able to start that job remotely, but so far, that’s not been disclosed or developed as an exploit. Margaritelli also spoke of other bugs as-yet unrevealed.

Take all the above info and decide for yourself how at-risk you are, and what steps to take. Us vultures simply removed cups-browsed from our Linux boxes. Margaritelli reckons there are a few hundred-thousand at-risk devices on the public internet.

He previously complained in a social media thread that his bug reports weren’t being taken seriously enough, and decided to go fully public after feeling that he was hitting resistance from fellow developers. He warned he would reveal all about a vendor-rated 9.9-out-of-10 CVSS severity hole in Linux.

It now appears an engineer at IBM’s Red Hat had reckoned at least one of the bugs was a 9.9 – making it a doomsday flaw – though given the user interaction needed, we believe the exploit chain should be considered less than highly critical. In his write-up today, Margaritelli said he thinks 9.9 is too high, too.

“Impact-wise I wouldn’t classify it as a 9.9, but then again, what the hell do I know?” he wrote.

Prior to today’s disclosure, watchTowr CEO and founder Benjamin Harris opined this is “not the watershed moment it has been made out to be.”

After we all learned more about the CUPS issues, he urged organizations to “immediately determine their exposure before they are forced to respond to an inevitable breach/cyber security incident,” but also noted “the vulnerability impacts less than a single-digit percentage of all deployed internet-facing Linux systems.”

“I continue to strongly believe that rapid reaction to emerging threats like this is one of the most powerful capabilities security teams should be leveraging and arming themselves with to prevent security breaches,” he told The Register.

“Now that the information about these vulnerabilities is public, the ‘bad guys’ will certainly be weaponizing this vulnerability to gain access to vulnerable systems.”

My CUPS over runneth

In addition to exposing those vulnerabilities, Margaritelli’s write-up also highlighted flaws in the bug-reporting process, Sonatype CTO Brian Fox told The Register. Notably, someone was able to leak Margaritelli’s private disclosures to CERT VINCE, intended for vendors, to a cyber-crime forum where it was shared on Tuesday.

“The details of this report were leaked publicly, forcing a rushed disclosure instead of an orderly path and rollout process,” Fox added, noting that Margaritelli had earlier raised the alarm of a leak.

“We should strive to make vulnerability disclosures more like hurricane warnings — providing timely and actionable information — and less like unexpected tornadoes that leave no time for preparation,” he said. “While these disclosures might sometimes seem exaggerated, it’s far better to be forewarned and ready than to be caught off guard by an unforeseen ‘tornado’ of security breaches.” ®

Editor’s note: Following disclosure of the bugs at 2000 UTC, September 26, this article was rewritten from this version to this at 2050 UTC in light of new information. It was then further revised at 0035 UTC, September 27, to this latest version.