Severe Unauthenticated RCE Flaw (CVSS 9.9) in GNU/Linux Systems Awaiting Full Disclosure
A critical security vulnerability affecting all GNU/Linux systems—and potentially others—has been identified by renowned security researcher Simone Margaritelli. The vulnerability, which allows for unauthenticated remote code execution (RCE), has been acknowledged by major industry players like Canonical and Red Hat, who have confirmed its severity with a CVSS score of 9.9 out of 10.
Margaritelli disclosed the existence of the vulnerability approximately three weeks ago but withheld specific details to allow developers time to address the issue. Despite this, there is currently no working fix available. Discussions between the researcher and developers have led to an agreed timeline for disclosure:
- September 30: Initial disclosure to the Openwall security mailing list.
- October 6: Full public disclosure of the vulnerability details.
Interestingly, there has been a delay in assigning Common Vulnerabilities and Exposures (CVE) identifiers to this issue. Margaritelli suggests that there should be at least three CVEs assigned, possibly up to six, due to the multifaceted nature of the vulnerabilities involved.
Canonical and Red Hat have not only confirmed the vulnerability’s high severity but are also actively working on assessing its impact and developing patches. However, some developers are reportedly debating the security impact of certain aspects of the vulnerabilities, which may be contributing to the delay in releasing a fix.
The lack of detailed information has left both individual users and security experts in a state of heightened concern. Without knowing which specific components, functions, or versions are affected, organizations are unable to take proactive measures to protect their systems.
Moreover, the absence of CVE assignments raises questions about the coordination and communication between security researchers, vendors, and the organizations responsible for vulnerability enumeration.
While a CVSS score of 9.9 indicates critical severity, it’s important to approach the situation with a balanced perspective. Not all high-severity vulnerabilities are easily exploitable in real-world scenarios. For instance:
- CVE-2024-7589: An SSH remote code execution vulnerability initially scored at 9.8 was later reevaluated to 8.1 due to the difficulty of exploitation.
- CVE-2024-38063: A Windows system RCE vulnerability with a CVSS score of 9.8 drew significant attention but was deemed very difficult to exploit after thorough analysis by security experts.
These examples highlight the importance of detailed technical analysis to fully understand a vulnerability’s impact.
While awaiting the full disclosure and subsequent patches, users and administrators should:
- Stay informed by following updates from trusted security news sources and official vendor communications.
- Review and enhance existing security measures, such as firewalls and intrusion detection systems.
- Prepare for rapid deployment of patches once they become available.
Update 1
On September 26 – A series of newly discovered vulnerabilities in CUPS, the popular print server used across Linux and other platforms, has stirred concern among security experts. The vulnerabilities, discovered by Simone Margaritelli and affecting CUPS on a range of operating systems, including Linux distributions, BSD variants, Oracle Solaris, and Google Chrome OS, could potentially allow remote attackers to take control of systems. With CVEs such as CVE-2024-47176, CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177, administrators are urged to act swiftly.
Margaritelli outlined in a detailed blog post how the flaws allow a remote unauthenticated attacker to replace existing printers’ IPP (Internet Printing Protocol) URLs or install new malicious ones. The danger here is that arbitrary commands can be executed on a victim’s machine when they initiate a print job.
What makes this vulnerability even more alarming is the fact that exploitation can occur remotely, across the public internet, via a simple UDP packet to port 631, assuming this port is left exposed on a network’s firewall. It also enables attacks within local networks, where attackers can spoof zeroconf, mDNS, or DNS-SD advertisements.
While the Linux kernel remains unaffected, the CUPS print server is widely used across various systems, increasing the potential impact. As of now, there is no available Linux patch to address the issue, leaving many systems exposed.
Exploiting these vulnerabilities requires the following conditions:
- The cups-browsed service must be manually enabled or started.
- The attacker needs access to the vulnerable system, either through:
- Unrestricted public internet access, or
- Gaining access to an internal network where local connections are trusted.
- The attacker advertises a malicious IPP server, creating a fake printer.
- A user on the victim machine sends a print job to the malicious printer.
- The attacker uses this opportunity to execute arbitrary code on the victim’s machine.
This chain of events leads to remote code execution, which could allow attackers to steal sensitive information or damage critical production systems. Even more concerning is that the attack can occur without any interaction beyond printing from the victim’s side, leveraging the trust within the local network or public-facing access points.
Red Hat, one of the organizations whose systems are affected by this group of vulnerabilities, has published a comprehensive response. Red Hat classifies the severity of these vulnerabilities as Important, although they clarify that RHEL systems are not vulnerable in their default configuration.
To detect whether your system is exposed, Red Hat recommends checking the status of cups-browsed:
$ sudo systemctl status cups-browsed
If the output shows “Active: inactive (dead)”, the system is not vulnerable. However, if cups-browsed is running or enabled, and the BrowseRemoteProtocols directive includes “cups,” the system is vulnerable.
To protect systems from these vulnerabilities, administrators are advised to stop the cups-browsed service with the following command:
$ sudo systemctl stop cups-browsed
Additionally, preventing the service from starting on reboot is essential for long-term protection:
Block Traffic to UDP Port 631: If disabling cups-browsed is not feasible, blocking all traffic to UDP port 631 can reduce exposure.
$ sudo iptables -A INPUT -p tcp –dport 631 -j DROP
$ sudo iptables -A INPUT -p udp –dport 631 -j DROP
Image: Shodan.io
Image: FOFA
Advisories and all bugs have been published:
- https://github.com/OpenPrinting/cups-browsed/security/advisories/GHSA-rj88-6mr5-rcw8
- https://github.com/OpenPrinting/libcupsfilters/security/advisories/GHSA-w63j-6g73-wmg5
- https://github.com/OpenPrinting/libppd/security/advisories/GHSA-7xfx-47qg-grp6
- https://github.com/OpenPrinting/cups-filters/security/advisories/GHSA-p9rh-jxmq-gq47
OpenPrinting has started publishing fixes as well now:
- CVE-2024-47175: https://github.com/OpenPrinting/libppd/commit/d681747ebf
- CVE-2024-47076: https://github.com/OpenPrinting/libcupsfilters/commit/95576ec3
- A temporary workaround for CVE-2024-47176 in: https://github.com/OpenPrinting/cups-browsed/commit/1debe6b140c
Update 3
Canonical’s security team has issued updates for several CUPS packages, including cups-browsed, cups-filters, libcupsfilters, and libppd, across all supported Ubuntu LTS releases. Upgrading these packages and restarting the CUPS daemon is strongly advised.
If this is not possible, the affected components can be targeted:
The unattended-upgrades feature is enabled by default from Ubuntu 16.04 LTS and onwards. This service:
- Applies new security updates every 24 hours automatically
- If you have this enabled, the patches above will be automatically applied within 24 hours
- However, we still recommend restarting the CUPS daemon using systemctl restart cups.service
Mitigation
- Desktop computers: Removing cups-browsed or disabling network protocols would hinder network printer discovery.
- Print servers: Disabling network printer detection could be a temporary fix, as existing printers remain accessible. However, on Ubuntu, modifying the configuration file could disrupt future automatic updates. We advise against this unless absolutely necessary, and if done, the original configuration should be restored after applying updates.
The following mitigation steps remove a print server’s ability to detect new network printers and stop the injection of the malicious PPD file:
- Edit /etc/cups/cups-browsed.conf
- Search for the BrowseRemoteProtocols configuration option
- Set the option to none (the default value is “dnssd cups”)
- Restart cups-browsed using systemctl restart cups-browsed
