You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A series of bugs in the CUPS printers discovery mechanism (`cups-browsed`) and in other components of the CUPS system, can be chained together to allow a remote attacker to automatically install a malicious printer (or hijack an existing one via mDNS) to execute arbitrary code on the target host as the `lp` user when a print job is sent to it.
As a reference useful to understand what follows, the main flow is:
0. cups-browsed discovers a printer either via UDP probe or DNS-SD.
1. it connects to the IPP server reported by the advertisement and fetches its properties.
2. these properties are saved to a temporary PPD file used to describe the printer to the rest of the system.
The following report explains how to exploit this in order force the service to write user controlled data to the temporary file and ultimately achieving code execution via network request.
I'm attaching a cups.mp4 video of a the full remote code execution chain against cups-browsed 2.0.1 on Ubuntu 24.04.1 LTS.
### Forcing it to connect to a malicious IPP server via discovery
The `cups-browsed` component is responsible for discovering printers on a network and adding them to the system. In order to do so, the service uses two distinct protocols.
For the first one, the service binds on all interfaces on UDP port 631 and accepts a custom packet from any untrusted source (bug number 1):
This is the first and most severe attack vector as it's exploitable from outside the LAN if the computer is exposed on the public internet ( [https://www.shodan.io/search?query=port%3A631+pro…|https://www.shodan.io/search?query=port%3A631+product%3A%22CUPS+%28IPP%29%22] ).
The service also listens for DNS-SD / mDNS advertisements trough AVAHI:
In both cases, when a printer is discovered by either the UDP packet or mDNS, its IPP or IPPS url is **automatically** contacted by cups-browsed and a `Get-Printer-Attributes` request is sent to it:
Please note that it is enough for the IPP server to respond with a valid response in order for the printer to be added to the system and, if discovered via mDNS, an existing printer can be directly hijacked (its IPP url replaced with a malicious one) making it indistinguishable from the original one.
Most importantly (bug number 2) note that the `cfGetPrinterAttributes` API does not perform any sanitization on any of the IPP attributes returned by the server. Attributes that are then saved, as they are, in a temporary PPD file via `ppdCreatePPDFromIPP2`:
It is also possible to note how `ppdCreatePPDFromIPP2` doesn't perform any sanitization itself and in fact it just writes to the file any attributes contents:
This allows an attacker (see attached PoC) to return a malicious IPP attribute in the form of (`printer-privacy-policy-uri` is just one of the several attributes that can be used, the RCE was also confirmed with `printer-info`, `printer-name` and `printer-make-and-model`):
This will set the `cupsPrivacyURI` to a valid value but also add the `FoomaticRIPCommandLine` and `cupsFilter2` entries. Also notice the space between `culsFilter2` and the semicolon - its purpose is to bypass these trivial checks:
> Some time ago the cups-filters maintainers took over maintainership of the foomatic-filters part for CUPS as well, and integrated it cleanly into cups- filters. That's the reason for the blocker; recent cups-filters contain the newest foomatic code available. The former separate foomatic-filters package is now unmaintained.
In short, by relying on the fact that FoomaticRIPCommandLine can be used to execute ANY command, that IPP attributes are never sanitized and that the discovery mechanism trusts blindly anything coming from *:631 or mDNS, we achieve remote command execution on the system when a print job is triggered.
## How does an attacker exploit this vulnerability?
An attacker can exploit this vulnerability if it can connect to the host via UDP port 631, which is by default bound to INADDR_ANY, in which case the attack can be entirely remote, or if it's on the same network of the target, by using mDNS advertisements.
## What does an attacker gain by exploiting this vulnerability?
Remote execution of arbitrary commands when a print job is sent to the system printer.
## How was the vulnerability discovered?
A lot of curiosity (when I noticed the *:631 UDP bind I was like "wtf is this?!" and went down a rabbit hole ...) and good old source code auditing.
## Is this vulnerability publicly known?
No, the bugs are not known and the FoomaticRIPCommandLine vulnerability is known to be already patched (it isn't).
## Is there evidence that this vulnerability is being actively exploited?
Not to the best of my knowledge.
## Do you plan to publicly disclose this vulnerability yourself?
Yes, I already agreed on a 30 days disclosure embargo with the vendor, which will end on October 6. I'm open to extending it if anyone needs more time.
> Some time ago the cups-filters maintainers took over maintainership of the foomatic-filters part for CUPS as well, and integrated it cleanly into cups- filters. That's the reason for the blocker; recent cups-filters contain the newest foomatic code available. The former separate foomatic-filters package is now unmaintained.
In short, by relying on the fact that FoomaticRIPCommandLine can be used to execute ANY command, that IPP attributes are never sanitized and that the discovery mechanism trusts blindly anything coming from *:631 or mDNS, we achieve remote command execution on the system when a print job is triggered.
I'm attaching the exploit code, it uses the ippserver package ( [https://github.com/h2g2bob/ipp-server] ), run as `exploit.py ATTACKER_EXTERNAL_IP TARGET_IP`, will create the `/tmp/I_AM_VULNERABLE` file on the target machine when a print job is started:
Exploit An attacker can exploit this vulnerability if it can connect to the host via UDP port 631, which is by default bound to INADDR_ANY, in which case the attack can be entirely remote, or if it's on the same network of the target, by using mDNS advertisements.
Impact Remote execution of arbitrary commands when a print job is sent to the system printer.
Discovery A lot of curiosity (when I noticed the *:631 UDP bind I was like "wtf is this?!" and went down a rabbit hole ...) and good old source code auditing.