RCE bug in CUPS - No Patch Yet - OUCH
All, There is a remote code execution bug in CUPS with no patch as of yet: https://www.theregister.com/2024/09/26/cups_linux_rce_disclosed/ The article contains mitigation steps if you have a public facing (or untrusted local) CUPS server. -- David C. Rankin, J.D.,P.E.
On 2024-09-27 07:57, David C. Rankin wrote:
All,
There is a remote code execution bug in CUPS with no patch as of yet:
https://www.theregister.com/2024/09/26/cups_linux_rce_disclosed/
The article contains mitigation steps if you have a public facing (or untrusted local) CUPS server.
I followed this last night (20:00 UTC) when it was full disclosure. Part II will be interesting although maybe not for opensuse but rather from a security perspective. It will expose macos and airprint as vulnerable according to evilsocket (Simone Margaritelli). Did a little check with 1024 hosts on our network. 2 is exposed via the internet and port udp/631 and one is vulnerable. This is under Swedish conditions but if we extrapolate this 0.1% of the internet is vulnerable. -- /bengan
David C. Rankin wrote:
All,
There is a remote code execution bug in CUPS with no patch as of yet:
https://www.theregister.com/2024/09/26/cups_linux_rce_disclosed/
The article contains mitigation steps if you have a public facing (or untrusted local) CUPS server.
Hmm. I had a look at my laptop, as I use(d) cups-browsed to easily print in various locations. Had a look at cups-browsed.conf, and that has the BrowseAllow/Deny/Order options. So I set Order to 'Allow,Deny' and set Allow to the IP of our printhost. However, if I then start cups-browsed, and check open ports, it still says cups-brow 120068 root 7u IPv4 156935 0t0 UDP *:ipp So it's not really clear to me if that method is sufficient. The article doesn't help there... Any opinions?
On 2024-09-27 16:57, Pit Suetterlin via openSUSE Users wrote:
David C. Rankin wrote:
All,
There is a remote code execution bug in CUPS with no patch as of yet:
https://www.theregister.com/2024/09/26/cups_linux_rce_disclosed/
The article contains mitigation steps if you have a public facing (or untrusted local) CUPS server.
Hmm. I had a look at my laptop, as I use(d) cups-browsed to easily print in various locations.
Had a look at cups-browsed.conf, and that has the BrowseAllow/Deny/Order options. So I set Order to 'Allow,Deny' and set Allow to the IP of our printhost. However, if I then start cups-browsed, and check open ports, it still says cups-brow 120068 root 7u IPv4 156935 0t0 UDP *:ipp
So it's not really clear to me if that method is sufficient. The article doesn't help there...
Any opinions?
Isn't that lsof? lsof only shows (lsof -i :ipp) if port ipp (631) is open not what to do with it, right? I'd nmap my computer from another one: nmap -sU -T5 -p 631 <your_ip> -- /bengan
Bengt Gördén wrote:
On 2024-09-27 16:57, Pit Suetterlin via openSUSE Users wrote:
Had a look at cups-browsed.conf, and that has the BrowseAllow/Deny/Order options. So I set Order to 'Allow,Deny' and set Allow to the IP of our printhost. However, if I then start cups-browsed, and check open ports, it still says cups-brow 120068 root 7u IPv4 156935 0t0 UDP *:ipp
So it's not really clear to me if that method is sufficient. The article doesn't help there...
Any opinions?
Isn't that lsof? lsof only shows (lsof -i :ipp) if port ipp (631) is open not what to do with it, right?
Yes, that's what I was unsure about...
I'd nmap my computer from another one:
nmap -sU -T5 -p 631 <your_ip>
Ah thanks. I don't speak nmap, so I didn't think of that. It tells me PORT STATE SERVICE 631/udp open|filtered ipp That would strengthen the idea that above method is sufficient to block unwanted access to the port without needing to shut down the service...
On 2024-10-01 16:02, Pit Suetterlin via openSUSE Users wrote:
PORT STATE SERVICE 631/udp open|filtered ipp
That would strengthen the idea that above method is sufficient to block unwanted access to the port without needing to shut down the service...
Yes. This (open|filtered) means that nmap did not receive a response on that port. Normally you would get an ICMP response with "port unreachable" from the target system and nmap indicates that by saying "Closed". -- /bengan
participants (3)
-
Bengt Gördén -
David C. Rankin -
Pit Suetterlin