CUPS flaws enable Linux remote code execution, but there’s a catch


Under certain conditions, attackers can chain a set of vulnerabilities in multiple components of the CUPS open-source printing system to execute arbitrary code remotely on vulnerable machines.

Tracked as CVE-2024-47076 (libcupsfilters), CVE-2024-47175 (libppd), CVE-2024-47176 (cups-browsed) and CVE-2024-47177 (cups-filters) and discovered by Simone Margaritelli, these security flaws don’t affect systems in their default configuration.

CUPS (short for Common UNIX Printing System) is the most widely used printing system on Linux systems, and it is also generally supported on devices running Unix-like operating systems such as FreeBSD, NetBSD, and OpenBSD and their derivates.

One of its components is the cups-browsed daemon, which searches the local network for advertised network or shared printers and makes them available for printing on the machine. This is similar to how Windows and Macs can search the network for remote network printers to print to.

Margaritelli found that if the cups-browsed daemon is enabled, which is not on most systems, it will listen on UDP port 631. It will also, by default, allow remote connections from any device on the network to create a new printer.

He discovered he could create a malicious PostScript Printer Description (PPD) printer that could be manually advertised to an exposed cups-browsed service running on UDP port 631.

This causes the remote machine to automatically install the malicious printer and make it available for printing. If the user on that exposed server prints to the new printer, the malicious command in the PPD will be executed locally on the computer.

The command to execute when printing is added through a foomatic-rip filter, which executes commands on a device so that a print job is rendered correctly.

Commands added using the foomatic-rip filter
Commands added using the foomatic-rip filter (Simone Margaritelli)

Limited world impact

While this is a remote code execution chain, it should be noted from the start that attackers must overcome some obstacles to exploit the vulnerabilities and actually achieve remote code execution.

The first is that the targeted systems must have the cups-browsed daemon enabled, which is usually not enabled by default, to expose their UDP ports on a network. Then, the attacker has to trick a user into printing from a malicious printer server on their local network that suddenly appears on their machine.

“It is a chain of bugs that rely on spoofing a printer in your local network that is automatically added via network discovery if it is turned on at all – usually not in its default configuration. Then an unverified variable that is used to exploit other vulnerabilities in the CUPS system to execute code, but only when a print job is triggered,” said Ilkka Turunen, Field CTO at Sonatype.

“Good news then – it’s an RCE but with several mitigations, including the fact the attacker needs to be able to connect to a computer via UDP which is widely disabled on network ingress and the service is usually not on by default. It seems like the real world impact is low.”

For these reasons, Red Hat has rated the flaws as having an “Important” severity impact instead of critical.

While BleepingComputer’s tests showed that most of our Linux servers did not have the service enabled by default, one of our Ubuntu VMs did. Others have also noted on Twitter that cups-browsed was enabled by default on their Linux devices.

No patches, but mitigation measures are available

While patches are still in development, Red Hat shared mitigation measures requiring admins to stop the cups-browsed service from running and prevent it from being started on reboot using the following commands to break the exploit chain:

sudo systemctl stop cups-browsed
sudo systemctl disable cups-browsed

Red Hat users can also use the following command to find out if cups-browsed is running on their systems:

sudo systemctl status cups-browsed

If the result displays “Active: inactive (dead),” then the exploit chain is halted, and the system is not vulnerable. If the result shows “running” or “enabled,” and the “BrowseRemoteProtocols” directive contains the value “cups” in the configuration file /etc/cups/cups-browsed.conf, then the system is vulnerable.



Source link