Simone Margaritelli, the author of the OpenSnitch firewall and the bettercap network analyzer, prematurely disclosed information about previously announced critical vulnerabilities that allow remote attacks on the GNU/Linux, Solaris, FreeBSD distributions and some other BSD systems. The publication was initially scheduled for October 6, but due to a leak of information, it had to be released earlier, before most distributions could prepare their package updates. The vulnerabilities affect the CUPS print server and allow remote code execution in the system without authentication.
The researcher who identified the issue has prepared a working exploit prototype that uses a combination of several vulnerabilities to execute code remotely with the permissions of the CUPS print job processing user (usually the 'lp' user). The exploit allows an attacker to stealthily modify the user's printer settings or add a new printer connected to the attacker's running IPP server, which serves a specially crafted printer PPD description. Processing this PPD during the print job initiation leads to the execution of the attacker's code (it requires the victim to initiate printing on the attacker-replaced or substituted printer).
Systems with proxy server CUPS printing and a running cups-browsed process that accepts network connections on port 631 (UDP) are vulnerable. The attack can also be executed from a local network where protocols such as server zeroconf, mDNS, or DNS-SD are used for printing. Only cups-browsed configurations where the parameter BrowseRemoteProtocols in the file /etc/cups/cups-browsed.conf is set to 'cups' are vulnerable. In distributions with systemd, the status of the cups-browsed service can be checked with the command 'sudo systemctl status cups-browsed'.
The vulnerability affects all printing systems based on CUPS that use vulnerable versions of the packages cups-filters, libcupsfilters, libppd, and cups-browsed. Fixes are currently available only as patches (1, 2, 3) — the current versions cups-filters 2.0.1, libcupsfilters 2.1b1, libppd 2.1b1, and cups-browsed 2.0.1 are susceptible to vulnerabilities. The issue remains unfixed in distributions; you can monitor updates on the following pages: Debian, Ubuntu, RHEL, SUSE/openSUSE, Fedora, Arch, FreeBSD. As a workaround for protection until updates are installed, you can restrict external network access to UDP port 631, disable the cups-browsed service, or set the BrowseRemoteProtocols configuration to 'none'.
Identified vulnerabilities:
- CVE-2024-47176 — a vulnerability in the cups-browsed process, which creates a network socket accepting connections on port 631, is attached to all network interfaces present in the system and accepts IPP requests 'Get-Printer-Attributes' from any external systems. By manipulating this service, an attacker can add a printer controlled by them to the system and exploit vulnerabilities in other CUPS components through the transmission of PPD configuration.
- CVE-2024-47177 — a vulnerability in the foomatic-rip handler from the cups-filters suite, allowing for code execution through the transmission of the FoomaticRIPCommandLine parameter in the PPD file, which an attacker can deliver via the aforementioned vulnerability in cups-browsed. The shell commands specified in the FoomaticRIPCommandLine parameter are executed as is, without consideration for the fact that the parameter may be set by an outside entity. For example, to write to the file /tmp/VULNERABLE, one might specify 'FoomaticRIPCommandLine: echo 1 > /tmp/VULNERABLE'.
- CVE-2024-47175 — a vulnerability in libppd, caused by a lack of validation of the ppdCreatePPDFromIPP2 value when writing IPP attributes to a temporary PPD file. This issue allows arbitrary data to be substituted in the resulting PPD file by attaching attributes using a newline character. For example, it is possible to bypass validation and include the FoomaticRIPCommandLine attribute alongside permitted attributes to exploit the aforementioned vulnerability in cups-filters.
- CVE-2024-47076 — a vulnerability in the libcupsfilters library from the cups-filters package, related to the lack of validation of the cfGetPrinterAttributes5 values returned by external IPP servers, which allows an attacker to process arbitrary IPP attributes in other CUPS subsystems, for example, when generating PPD files.
The attack scenario involving CUPS consists of the following steps:
- The attacker deploys their own IPP server.
- Sending the victim a UDP packet containing a link to a printer bound to the attacker’s running IPP server.
- Upon receiving this packet, the victim's system connects to the attacker's IPP server and requests the printer attributes.
- In response to the victim's request, the attacker's IPP server returns a PPD file with attributes, including the FoomaticRIPCommandLine attribute. This attribute is attached to one of the permissible attributes using the "\n" character in one line (for instance, "cupsPrivacyURI: "https://www.google.com/\n*FoomaticRIPCommandLine: "), which allows bypassing the check and leads to FoomaticRIPCommandLine being recorded as a separate attribute when saving the received data to a temporary file.
- As a result of processing the transmitted attributes, a PPD file is created in the victim's system: ... *cupsSNMPSupplies: False *cupsLanguages: "en" *cupsPrivacyURI: "https://www.google.com/" *FoomaticRIPCommandLine: "echo 1 > /tmp/I_AM_VULNERABLE" *cupsFilter2 : "application/pdf application/vnd.cups-postscript 0 foomatic-rip" *cupsSingleFile: True *cupsFilter2: "application/vnd.cups-pdf application/pdf 0 -" ...
- When printing to the spoofed printer set up by the attacker on the victim's system, the command "echo 1 > /tmp/I_AM_VULNERABLE" will be executed.
The researcher who discovered the vulnerabilities notes that it took a couple of days to find the vulnerability, but then followed a prolonged 22-day correspondence with the OpenPrinting project developers in an attempt to persuade them of the seriousness of the problem and the need to prepare patches. The discussion became mired in disputes about whether to fix the mentioned issues at all, and the situation was only turned around by raising public awareness about the critical problem. It's also interesting that a leak of information occurred, during which a confidential report and exploit submitted to CERT appeared publicly on the breachforums.st forum, despite an embargo on information disclosure.
Source: opennet.ru
