Connect with us

Tech

Printer bug sends researchers into uproar, affects major Linux distros

Published

on

Printer bug sends researchers into uproar, affects major Linux distros

A series of vulnerabilities impacting nearly all major Linux distributions that  became the talk amongst cybersecurity professionals on Thursday appears to fall short of the “next Log4Shell” hype and can be fixed with a simple remediation. .

The bugs impact OpenPrinting CUPS (Common Unix Printing System), the default printing system found in most popular versions of Linux, like Red Hat, Debian, and Canonical’s Ubuntu. While CUPS is installed on most Linux systems, it often isn’t configured to handle printing tasks, which is needed for the vulnerabilities to be exploited in an attack. 

Additionally, for most systems, CUPS has to be manually enabled and the attacker has to have access to the server. The affected server also has to have public internet and local network connections access.

Luckily, this spares cyber defenders from immediate widespread impact, said Brian Fox, co-founder and chief technology officer for the open-source cybersecurity firm Sonatype.

“This means that although an attacker can plant the malicious device, they cannot exploit the vulnerability unless a print job is sent to it,” Fox said. “However, this situation is concerning because future attacks following a similar pattern might not require a print job to trigger and could exploit similar vulnerabilities.”

Simone Margaritelli, a vulnerability researcher who made the discovery, reported the bugs and exploit chain weeks ago but says he had difficulty with the process. Margaritelli, who initially planned to disclose the bug next week, took to social media Thursday morning to warn that something urgent was coming, while also noting there should have been additional CVEs assigned as well.

“If your software has been running on everything for the last 20 years, you have a freaking responsibility to own and fix your bugs instead of using your energies to explain to the poor bastard that reported them how wrong he is, even tho he’s literally giving you [Proof of Concept] after [Proof of Concept] and systematically proving your assumptions about your own software wrong at every comment,” he posted on X. “This is just insane.” 

Later Thursday, Margaritelli claimed the embargo was dropped because his initial report — exploit included — was leaked by the Vulnerability Information and Coordination Environment (VINCE), the CERT coordination center run by Carnegie Mellon University. Margaritelli’s blog post included a screenshot of a submission on the cybercrime forum BreachForums on Tuesday, which detailed his submission to VINCE. He told CyberScoop in an email did not submit the information anywhere else.

In all, four vulnerabilities were created due to Margaritelli’s research:

CVE-2024-47176 cups-browsed version 2.0.1 and below

CVE-2024-47076 libcupsfilters version 2.1b1 and below

CVE-2024-47175 libppd version 2.1b1 and below

CVE-2024-47177 cups-filters version 2.0.1 and below

Matthiew Morin, head of product with the XIoT security firm NetRise, said the bug could still be a “big deal” for servers that might be affected. Shodan, a search engine that indexes information about internet-connected devices, posted on X Thursday that there are “at least 75,000 exposed CUPS daemons on the Internet.”

Morin said operators they work with running IoT devices often “have no idea what software is running on them let alone being able to manage and secure these devices.”

“From a remediation perspective, it’s pretty ‘simple,’” he said. “The problem is that it’s installed on pretty much every Linux system by default.”

Red Hat noted that users can check if they are vulnerable by running: sudo systemctl status cups-browsed

Margaritelli’s blog post lists the following directions for remediation: 

  • 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.

Written by Christian Vasquez

Christian covers industrial cybersecurity for CyberScoop News. He previously wrote for E&E News at POLITICO covering cybersecurity in the energy sector. Reach out:  christian.vasquez at cyberscoop dot com

Continue Reading