Exploit of a combination of several bugs - Overhyped but not that severe - Fixes already available
…
Canonical’s security team has acted immediately to quickly apply the patches which Michael Sweet (author and maintainer of CUPS) had already prepared for CUPS, cups-browsed, libcups-filters, libppd, and cups-filters (in the time from the first report until then I was some days off and I was also on the Open Source Summit Europe, thanks, Michael Sweet, for stepping in, also thanks to Zdenek Dohnal from Red Hat) to the appropriate in all supported Ubuntu versions, so that at the time of disclosure most fixes were already in place. They also reported in an Ubuntu blog. They tell users what to do, from turning off cups-browsed or at least its legacy CUPS browsing support to updating their systems as the fixes were already available. Thanks a lot to Seth Arnold, Marc Deslauriers, Diogo Sousa, Mark Esler, Luci Stanescu, and more.
…
The X post really overhyped the vulnerability. Attacks from the internet are not very probable due to the fact that servers on the internet do not have cups-browsed and CUPS installed and CUPS/cups-browsed setups are there usually only in NAT-protected local networks with desktop machines and print servers. And the remote code execution is also rather restricted, as CUPS filters are not running as root, but as the system user “lp” which cannot even read user’s home directories. In addition, the remote code execution only happens when a user actually prints a job on the fake printer. Actually assigned scores ended up between 8.4 and 9.1.
Yep. While simple to prepare, this will affect almost nobody, as it requires the user to perform an increasingly rare action in a world that’s often going paperless.
Also, the likelihood that a regular user will expose port 631 to the internet is probably close to zero. There’s several uncommon pieces that have to be in place for this to work, to the point that it’s not a simple matter to execute this exploit.
Is that really true? From https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/
The very next sentence:
They said they were getting duplicates and non-*nix hits with that 300k number, which doesn’t help them (i.e. the hundreds of thousands of hits was artificially inflated). So yes, the threat is overblown.
Coupled with the fact that patches are already out, and it’s easily mitigated by closing 631, and I don’t expect this will be much of a problem for most people.
I’m not sure why you say it’s “artificially” inflated. Non-linux systems are also affected.
How’s that? If I’m running a Windows machine, how would a CUPS exploit affect me?
I’m not asking maliciously, but I genuinely don’t grasp how that could be a viable attack vector.
You would be vulnerable on Windows, if you were running CUPS, which you probably are not. But CUPS is not tied to Linux, and is used commonly on e.g. BSDs, and Apple has their own fork for MacOS (have not heard anything about it being vulnerable though).
Wait, which list of filtered IPs are you even talking about? The list in the article is a list of unique kernel versions, not IPs.
My guess is that most hits that scan is gonna catch is old enterprise networks, that has not been updated or maintained by security.
ipv6 doesn’t give the NAT. A malicious website can mount the attack.
How?
Say I host a malicious server with ipv6 only. You visit the site without NAT. I get your ip and ip:631 is open (unless firewall and listen is restricted to prefix). Usual attack afterwards.
Edit: You need to have ipv6, for example many mobile networks.
I have full IPv6, none of my ports that I haven’t explicitly whitelisted in the firewall can be accessed from the Internet. I can open a host completely, but it’s not default. This is on the most common brand of consumer routers here.
Just because it’s not NATted doesn’t mean there’s no firewall in place.
Yeah ofcourse firewall is the good idea here. I personally have firewall on on every device so that I can manage what can connect and from where.
The point is though often people just disable firewalls (some distros do not install/enable by default too) to workarround certain issues quickly like kdeconnect not connecting, bridge not working and such. That’s how I think the whole ‘ipv4 NAT is the best (consumer) firewall’ concept came popular.