Skip to main content

Zero-day RCE vulnerability found in CUPS - Common UNIX Printing System

Écrit par:
feature-insights-context

27 septembre 2024

0 minutes de lecture

On September 27, 2024, evilsocket.net (Simone Margaritelli) published information about several vulnerabilities in CUPS (Common UNIX Printing System), which can allow for arbitrary remote code execution (RCE). There are currently 4 CVEs associated with these findings, with potentially more on the way. There is also some debate about the severity of these vulnerabilities, however, one of the CVEs was initially given a CVSS score of 9.9. We will update this blog if new information becomes available.

Important note: there may be other CVEs issued related to these vulnerabilities and others detected by Simone, the original researcher. We will update this blog with new details as needed.

What we currently know

A new zero-day vulnerability impacting the Common UNIX Printing System (CUPS), a popular printer support package, has been identified. It impacts downstream packages cups-browsed, libcupsfilters, cups-filters, and libppd. The vulnerabilities allow for unauthenticated remote code execution (RCE) and at least one has been assigned a CVSS score of 9.9. However, the exploitability of the vuln is limited to servers with the CUPS service enabled and requires either access to UDP port 631 (note that it is possible to remap CUPS to a different port), which is more common for external network access, or DNS-SD, which is more common for internal networks.

There are several advisories related to this vulnerability:

The vuln currently impacts all previous versions of the following packages:

  • distrotech/cups-filters - all versions

  • OpenPrinting/cups-filters - all versions

  • cups-browsed - all versions

  • libcupsfilters - all versions

  • libppd - all versions

CUPS has been part of UNIX and Linux operating systems since 1999 and is widely distributed with many UNIX and Linux distributions, Apple, Windows, and other operating systems. CUPS provides print services and, as a result, typically listens for network requests, making it susceptible to RCE vulnerabilities and attacks.

How to prepare for remediation

Snyk detects the vulnerabilities with both Snyk Open Source and Snyk Container, including detecting unmanaged C/C++ packages. Additionally, Snyk and our runtime security partners can indicate if you have running containers with the vulnerability, and in many cases, can determine if the affected CUPS processes are loaded in the container while it’s running and whether the container is configured for network access.

  • Check your container and package usage to gauge your exposure to CUPS.

  • Determine if you truly need CUPS and consider removal or deactivation if you do not.

  • Where you are certain CUPS is unnecessary, you should consider blocking access to UDP port 631 from external networks. You may also consider blocking DNS-SD traffic for internal traffic, but be aware that DNS-SD is used for more than CUPS, so further investigation may be required.

Snyk Open Source 

To detect the affected packages with Snyk Open Source, use the snyk test command, or if you have C/C++ code and libraries, use the snyk test --unmanaged command. Any previously scanned projects being monitored by Snyk Open Source will automatically be retested and you can check those projects.

Importing your project into Snyk using our supported SCM integrations (GitHub, Bitbucket, GitLab, Azure Repos) will automatically trigger a test, which will enable you to use the Snyk UI to identify, prioritize, and fix these vulnerabilities in your projects. 

  • Snyk CLI and CI/CD integrations:

    • snyk test for most languages

    • snyk test --unmanaged for C/C++ projects

    • You can also use snyk monitor to provide ongoing monitoring of these projects

  • Source code managers:

    • Automatic detection on new imports

    • Automatic rescanning of existing projects is underway

    • Daily updates of existing projects is default and automatic

  • IDE:

    • Snyk’s IDE plugins make use of the Snyk CLI and will detect these vulnerabilities during a scan

Snyk Container

To detect the affected container images with Snyk Container, use the snyk container test command. If you already have projects that have been scanned and are being monitored by Snyk Container, your projects will automatically be retested and you can check those projects now.

Snyk CLI and CI/CD integrations:

  • snyk container test will check both the container image and look for language manifests (e.g. package.json) to detect usage.

  • snyk container monitor will also scan and detect and provide ongoing monitoring for future vulnerabilities.

  • Container registries:

    • Containers scanned via registry integrations will automatically look for these vulnerabilities on import.

    • Existing imported container projects will alert to the presence of this vulnerability.

  • Source code managers:

    • Snyk Container scans Dockerfiles during SCM imports but only checks the parent image (the FROM command) and reports vulnerabilities only for some Docker Certified parent images. If the parent image is covered and has this vulnerability, it will be reported. However, a scan of the actual container images after the build is the most reliable method of detection.

Prioritization using Snyk’s Risk Score

You're likely to identify multiple cups issues in your projects, which can cause confusion as to where to focus your fix efforts first. Snyk’s Issue Risk Score incorporates many risk factors to help you quickly identify issues that should be addressed first. The score includes a number of signals, such as EPSS, exploit maturity, CVSS, social trends, and more, and can then be used to quickly sift through the list of vulnerabilities and prioritize fixes accordingly. 

The score is displayed for each detected issue on the Projects page and is also available within Snyk’s reports.

1_Zero-day_RCE_vulnerability_found_in_CUPS_-_Common_UNIX_Printing_System

Snyk Reports

There is a new report available in Snyk’s “Featured Zero-Day” report list for this set of vulnerabilities. If you have an Enterprise plan you can access this report by clicking “Reports” in the left hand navigation (both Group level and Org level reports are available). By default this presents the “Issues Detail” report but you can click “Change Report” drop-down next to the report title and select “Featured Zero-Day”. Then on the following screen, select the CUPS report from the Zero-Day drop-down list.

2_Zero-day_RCE_vulnerability_found_in_CUPS_-_Common_UNIX_Printing_System

You can also use CVE in conjunction with other filters in the Issues Detail, Issues Summary, Vulnerabilities Detail, and SLA Management report to create, save, and share your own custom reports to track this vulnerability across all Snyk Open Source and/or Snyk Container detections. Filter reports and other pages for CVEs: CVE-2024-47177, CVE-2024-47176, CVE-2024-47076 and CVE-2024-47175. 

The video below shows filtering for one CVE, but you can include as many as you’d like at one time:

3_Zero-day_RCE_vulnerability_found_in_CUPS_-_Common_UNIX_Printing_System

Snyk AppRisk Pro

If you’re using Snyk AppRisk Pro, the Insights funnel in the Issues screen will pinpoint live running instances of applications that have these vulnerabilities and also have external network access. Again, you can add a filter to focus on just these issues if you would like.

4_Zero-day_RCE_vulnerability_found_in_CUPS_-_Common_UNIX_Printing_System

What is Snyk doing?

Snyk security experts are actively following release updates, vulnerability information, social media chatter, and more to give our customers any incoming data. Additionally, research is being conducted to find any additional downstream packages that may be affected. We will update this blog as necessary. If you have any questions about these vulnerabilities, feel free to reach out to us via the Snyk Community Discord, or you can sign up for a free trial to determine if you are impacted by these vulnerabilities

feature-insights-context

Vous voulez l’essayer par vous-même ?

Snyk interviewed 20+ security leaders who have successfully and unsuccessfully built security champions programs. Check out this playbook to learn how to run an effective developer-focused security champions program.