New big vulnerability announced (CVSS 9.9)

F

fmc000

Link here.

A critical security vulnerability affecting all GNU/Linux systems—and potentially others—has been identified
Click to expand...

We'll see if we are included in the "potentially others". In our company we opened a few SR to our vendors and one of them told us that they are assisting the maintainers and honoring embargo holds.
 
Yes, I saw this and had the same thought in terms of what does "potentially others" mean for *BSD?

October 6th is apparently the big reveal date so a week or so to wait and find out.
 
Maybe if you run port 631 to outside world you deserve this.


Code: 
udp_services="{67,68,53,123,514,27950,27960}"#{dhcp,domain,123/ntp,syslog-ng,openarena}#
 
Uhm, I'm a bit disappointed, considering the huge drama (which btw continues in this disclosure, I mean, nothing unusual about listening on INADDR_ANY for getting UDP broadcasts, at least by default ...)

Sure, these are a couple of serious flaws. But in the end, you'll have the cups user execute arbitrary code if someone has (insanely) cups-browsed publicly exposed and someone is stupid enough to send a job to a magical mystery printer that suddenly appeared.

I have the feeling this memory corruption in the packet parser that's just touched shortly might be more interesting in the end, possibly allowing root compromise ...
 
Phishfry said:
He says no authentication but manual says otherwise:
Click to expand...
There's no authentication in cups-browsed, and that's by design, it SHOULD just catch any broadcast from a (local!) IPP printer and add it. It shouldn't be enabled by default but only on explicit administrative action...
 
Few month ago in one office was strange mass loosing printer, connected via cups-browsed, directly and FreeBSD VM (print server). Suddenly began, suddenly stopped. Tons of forum posts over internet shows this strange thing since 2019, even earlier. Exactly in that manner -- suddenly began, suddenly stopped. Salvation was to disable cups-browsed and manual add printer. Office machines was Linux Mint and Debian with Chromium browsers and LibreOffice.

Who know, maybe there is way to attack LAN through javascript in browser.
 
exactly ... I have expected something serious, considering "Unauthenticated RCE vs all GNU/Linux systems (plus others) disclosed 3 weeks ago" and not something on cups daemon that 98% of GNU/Linux systems do not even have that installed. Just some researcher who does want to have some attention, nothing more.
 
Phishfry said:
So this does nothing?

encryption=requiredSpecifies that the connection to the IPP printer should be encrypted using TLS.

Click to expand...
Maybe it would force doing the initial connection TO the discovered printer via https? Which would achieve exactly nothing against the attack presented. And btw, encryption is not authentication.

The broadcast message cups-browsed wants to receive is neither encrypted nor authenticated (and doesn't have to be, nothing to protect here, the flaws consider how it's handled plus some hacky crap later in the chain to have "quick&dirty" drivers for non-postscript printers)
 
The sad thing is, these are very relevant findings (and again, I have a funny feeling about this buggy parser, if that's exploitable, it wouldn't require user interaction either!). But as presented, with all the drama reeking of attention whore, someone missed a chance to build karma for sure...
 
Actually it looks like that you can install a fake printer on a machine using this method and embed into the ppd all the commands you like; they will be executed whenever a printer job is invoked. These commands are run with root privileges.
 
zirias@ said:
The broadcast message cups-browsed wants to receive is neither encrypted nor authenticated (and doesn't have to be, nothing to protect here, the flaws consider how it's handled plus some hacky crap later in the chain to have "quick&dirty" drivers for non-postscript printers)
Click to expand...
That's why I have been putting printers in their own vlan that can't access the outside world for many years now. The CUPS server (jail) then connects to that printer-network and either the client network or DMZ from where it is only accessible via TCP on port 631.

Regardless of such additional measures; CUPS runs as its own, non-privileged user, so even by default it's not "total loss of integrity" and as already was pointed out: everyone running CUPS publicly accessible 100% deserves being powned.


I've read (overflown) that writeup twice by now, and not only the manner how these (valid) bugs and security flaws are being presented and combined, but also the wording of many parts and *especially* the accompanying theatralic mud-flinging on twitter/X is a textbook example of an attention whore. I wonder if he approached the devs and security officiers with the same abrasive attitude, then It's no wonder he got that much backlash.
I also have a feeling that 2 of these vulnerabilities might have much deeper implications and could be exploited in far more serious ways - maybe those will come in the next writeups he announced? But then - publishing the same vuln/CVE multiple times with different PoCs is also highly unprofessional and nothing but karma farming...


edit: Oh, and hiding on X behind "protected posts" so one has to follow to read the posts also adds to the already strong odor of attention seeking.
 
1727423218254.png


So it will be all about the same vulnerabilities exploited in different ways...


(And yes, I will unfollow him in a few hours if he's not coming up with something really serious that is worth calling "Unauthenticated RCE vs all GNU/Linux systems" and not just some cups-specific vulnerabilities)
 
infosec.exchange

Will Dormann (@wdormann@infosec.exchange)

Attached: 2 images So this "CVSS 9.9" "unauthenticated RCE vs all GNU/Linux systems (plus others)" thing... - Does NOT affect all GNU/Linux systems. - Is not CVSS 9.9. I put it at a 6.3 It also requires: 1) The victim system has no active firewall to block incoming connections. 2) A user on...
infosec.exchange infosec.exchange
backlash spreading ...
 
So basically someone maliciously announces a printer that appears in your printer list that a user would then need to print to?
Hmm.
 
Yes. Not saying that's impossible (hey, call it "ghostscript PDF printer" or whatever and hope for the best ?), but even then, in any sane installation you'll run something as some unprivileged local service account.

It's still bad, but far from the announced end of the world.
 
  • Like
Reactions: mer
sko, no, look at the patch again, it leaves the AVAHI (dnssd) option for browsing when the port option is enabled, and removes the "native" (cups) protocol in both cases.

I don't specifically like the patch though, cups-browsed is actually useful (and configured on my machines to only listen for notifications from my legitimate print server ... I mean, I don't need a vulnerability to configure services in a sane way :rolleyes:). As cups-browsed must be actively enabled in FreeBSD's port, this looks like an attempt to prevent people from shooting their own foot, I didn't think FreeBSD is doing that, but maybe it's just for avoiding any simplified criticism. I assume it will be reverted once the real fixes are available.
 
You must log in or register to reply here.
Back
Top