Hi Peter, hi.

Peter Duffy - 26.09.24, 22:55:57 CEST:
> These have appeared in the last hour or so:
>
> https://gist.github.com/stong/c8847ef27910ae344a7b5408d9840ee1
>
> https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Pa
> rt-I/
>
> CUPS (specifically cups-browserd)
>
> Personally, I'm waiting for a few analyses of the above before I do
> anything drastic.

Okay, so there is indeed something. Thanks, Peter, for posting this! I
used this to double check on my systems to make sure they are not affected.

Additionally to cups-browsed not installed on any of my systems on this
laptop I have CUPS listening on TPC 127.0.0.1:631 and [::1]:631*only*.

And I bet this is even the default on Debian/Devuan, since I do not
remember changing that.

I usually check on open ports after installing a system or after bigger
updates, especially when it is a desktop based system.

Anyway anyone should make sure "cups-browsed" is not running and
preferably not installed at the moment.

On none of the Linux servers I maintain CUPS is even installed. A Devuan
based server had libcups2 as a probably indirect dependency of
ghostscript. Which may have been installed as a recommendation from some
PHP related package installed as a recommendation requirement for
Nextcloud probably php-imagick. I removed ghostscript for now on this
server even though no 631 port was open. I do not think systems with
libcups2 without anything else from CUPS installed are affected, but for
now I play it safe and rather risk some loss in functionality in
Nextcloud. I have always been vary Nextcloud wanting to have php-imagick
and thus (parts of) Imagick installed and rather let it complain about
missing Imagick SVG support than installing this as well. Even though
meanwhile by default Imagick is quite locked down in Debian. Too locked
down for some use cases on desktop systems.

On an Alpine based system with another instance of Nextcloud no CUPS
related package is installed. Alpine is very nice in that regard. Only the
stuff you actually installed is there. I really love this minimalist
approach.

So while there is considerable impact on Internet facing systems where
cups-browsed is installed and running… I still think this set of bugs is
over-hyped. Yes, according to the report there are several hundred
thousands of them, but that has been and probably still is true for
completely unprotected MongoDB servers or servers with open telnet port
etc. pp.

And while I thank Simone Margaritelli who analyzed and reported those
issues, cause it helps to make CUPS and Linux distributions safer, I still
disagree with the way of disclosure.

The report is quite elaborated and well done is what I can tell from
browsing over it. It must have taken quite some time to write it. But… at
the same time formulated in a somewhat arrogant and ego driven way.
Actually I have seen this often enough. I still remember the LibreSSL
story which amused me quite a bit:

https://www.openbsd.org/papers/bsdcan14-libressl/

(link from https://www.libressl.org/papers.html)

I may read this new report completely and thoroughly cause technically it
appears to be very well done to me. Like the LibreSSL story linked above
as well.

Regarding the OpenSSL issues back then the impact was much more severe.
Like in a huge lot more severe. I also still remember DSA-1571-1¹. I will
probably never forget that number. I have been using distkeys² to remove
SSH keys like crazy from a lot of systems back then. As far as I can tell
I have been quick enough back then. Or lucky – that no one attacked
before.

On the other hand even the OpenSSL related report from a LibreSSL
developer did not really take into account overworked developers and
maintainers. While I laughed on some of the very dire programming mistakes
elaborated in that report… I meanwhile see both sides of the story and
wonder how many developers work on cups-browsed. However it appears to me
the report by Simone Margaritelli can make for a good laugh as well as it
also seems to be formulated in a somewhat sarcastically toned humorous
way.

Simone Margaritelli complained about how trying to responsibly disclosing
has failed for him. I did not yet read up the details, but if that is
just, then there is really another important issue to look at: How
responsible disclosure processes are handled by affected parties.

The most important lesson from this IMHO: Always check open ports and make
sure any Internet facing service which is not supposed to be running on a
given system actually is not running and preferably not even installed.

And for distributions setting up cups-browsed by default: Don't. AFAIK in
most of the home use cases it is not even needed. It should be opt in.

Anyway as far as I can see this set of security issues are not the end of
the world. By far not.

[1] https://lists.debian.org/debian-security-announce/2008/msg00152.html

[2] https://github.com/proact-de/distkeys (not maintained anymore and
unless Ruby Net:SSH crypto stuff has been updated, not compatible with
common hardening of OpenSSH servers)

Best,
--
Martin