[HN Gopher] Attacking UNIX Systems via CUPS
___________________________________________________________________
Attacking UNIX Systems via CUPS
Author : NetBender
Score : 199 points
Date : 2024-09-26 19:59 UTC (3 hours ago)
(HTM) web link (www.evilsocket.net)
(TXT) w3m dump (www.evilsocket.net)
| RGBCube wrote:
| Anyone exposing CUPS to the internet is living a level of not
| giving a fuck that CVEs cannot reach.
| RGBCube wrote:
| I also cannot believe that _this_ is the 9.9 rated CVE. For
| comparison, heartbleed was a 7.5. I was awaiting a Total Linux
| Meltdown at best and a collapse of the world economy at worst
| with the amount of hyping up and fearmongering that the author
| did on social media.
| bogantech wrote:
| Link to the OP for those that haven't seen it:
| https://x.com/evilsocket/status/1838169889330135132
|
| Hyped it up to be some massive thing but it turned out to be
| a massive nothingbuger for me at least
| RGBCube wrote:
| Non-loginwalled link:
| https://threadreaderapp.com/thread/1838169889330135132.html
| maeln wrote:
| It's always funny to me how cybersecurity always seem to
| attract people with a ... certain sense of ego.
| ChocolateGod wrote:
| > pretty much only got patronized because the devs just
| can't accept that their code is crap - responsible
| disclosure: no more.
|
| I can think of another reason they got patronised.
| NavinF wrote:
| Yeah tbh it's not as bad as he claimed. I doubt this is
| actually rated 9.9:
|
| >A remote unauthenticated attacker can silently replace
| existing printers' (or install new ones) IPP urls with a
| malicious one, resulting in arbitrary command execution (on
| the computer) when a print job is started (from that
| computer).
|
| >WAN / public internet: a remote attacker sends an UDP packet
| to port 631. No authentication whatsoever.
|
| >LAN: a local attacker can spoof zeroconf / mDNS / DNS-SD
| advertisements (we will talk more about this in the next
| writeup ) and achieve the same code path leading to RCE.
|
| Still, sucks for linux desktop users. Looks like any random
| device on your wifi/vpn can screw you over
| floren wrote:
| Or any malicious user on the airport wifi. The compromise
| will linger until however many weeks later when you decide
| to print something...
| bremac wrote:
| Keep in mind that you still need send a print job to the
| fake printer to trigger the exploit. If you send the job
| to your real printer, nothing happens.
| rolph wrote:
| i knew there was a reason i blacklist
| unsolicited/unauthenticated UDP inbound.
| DanMcInerney wrote:
| It appears that the vulnerable service in question listens on
| 0.0.0.0 which is concerning, it means attacks from the LAN are
| vulnerable by default and you have to explicitly block port 631
| if the server is exposed to internet. Granted, requires user to
| print something to trigger which, I mean, I don't think I've
| printed anything from Linux in my life, but he does claim
| getting callbacks from 100's of thousands of linux machines
| which is believable.
| gordonfish wrote:
| This is why on public servers I block everything inbound and
| only allow specific needed services through.
| bongodongobob wrote:
| Who doesn't block all unneeded ports on an internet facing
| server or have it behind a firewall of some sort?
| bshipp wrote:
| I guess the important question is whether or not these
| things are blocked by default or require user intervention
| to disable cups? Sure, many of us block all ports by
| default and either route everything behind a reverse proxy
| or punch very specific holes in the firewall that we know
| are there and can monitor, but someone firing up an ubuntu
| distribution for their first foray into linux is probably
| not thinking that way.
| bongodongobob wrote:
| Well lots of people crash 600HP cars right after they buy
| them. If you haven't done your homework, you'll learn
| quickly.
| bshipp wrote:
| The people who are crashing their 600HP Linux systems
| are, unfortunately, not the ones who are reading CVE
| listings in their spare time. Canonical and other distros
| are probably going to have to patch that default setting.
| bongodongobob wrote:
| You don't need to read CVEs to turn on your fucking
| firewall. It's in every single how to set up a server for
| dummies tutorial I've ever seen.
| eikenberry wrote:
| Which distro do you see Cups listening on 0.0.0.0? On Debian
| (at least, only one I have handy) it only listens on
| localhost.
|
| [edit: I was wrong, it listens on 0.0.0.0 for UDP. I was only
| checking TCP. ]
| rini17 wrote:
| MX Linux
| cp9 wrote:
| on popOS I see 0.0.0.0:*
|
| I'm not sure why it deviates from Debian and Ubuntu which
| its based on though
| jeffbee wrote:
| That's the wrong column of netstat output, I think.
| "0.0.0.0:*" stands in for the (non-existent) peer address
| of a listening port.
| cp9 wrote:
| oh sorry yeah I copied the wrong column. the correct
| column is `0.0.0.0:631`
| bonzini wrote:
| OpenSUSE
|
| But it looks like cups-browsed is only needed on the
| Internet; locally you only need mDNS.
| mikepavone wrote:
| On my Ubuntu 22.04 machine, cupsd itself is only listening
| on localhost, but cups-browsed (which is what has the
| vulnerability here) is listening on 0.0.0.0
| raverbashing wrote:
| Why does it even listens in UDP at this day and age?!
| mikepavone wrote:
| I believe it's implementing DNS-SD for network printer
| auto-discovery. I'm not terribly familiar with DNS-SD,
| but given that normal DNS is UDP based it would be
| unsurprising for DNS-SD to also use UDP.
| ahoka wrote:
| DNS is actually UDP/TCP. It's probably required for
| receiving unicast messages, if it's using DNS-SD
| ahoka wrote:
| To receive multicast messages, probably.
| RGBCube wrote:
| I'm pretty sure all major distros configure it to listen
| locally instead.
| mikepavone wrote:
| cupsd is configured to listen locally, but cups-browsed has
| to listen on the network to do its job (network printer
| auto-discovery)
| gordonfish wrote:
| > but cups-browsed has to listen on the network to do its
| job (network printer auto-discovery)
|
| Isn't listening on 0.0.0.0 instead of localhost only
| needed if the machine itself is hosting a printer that
| needs to be accessible to other hosts?
| btown wrote:
| If you're vulnerable to attacks from the LAN, you're
| vulnerable to your wi-fi router (or your coffee
| shop/workplace's router) being compromised, which is quite
| common; see e.g.
| https://www.bleepingcomputer.com/news/security/mirai-
| botnet-... and https://blog.lumen.com/the-pumpkin-eclipse/
|
| Assuming that most routers are silently compromised, with
| their command-and-control operators just waiting for an
| exploit like this one, is almost par for the course these
| days!
| runjake wrote:
| The problem: you're thinking in terms of home/small
| business networks.
|
| The rest of us are thinking in terms of larger networks (in
| my case with hundreds of subnets and tens of thousands of
| nodes) where "631 is blocked at the firewall" isn't of much
| relief. The firewall is merely one, rather easy to get
| past, barrier. We're also concerned with east/west traffic.
| btown wrote:
| For sure, and sending hug-ops to teams like yours that
| have to deploy & enforce mass patches! But I'm also
| thinking of environments that don't even have the benefit
| of a team like yours.
| https://issuetracker.google.com/issues/172222838?pli=1 is
| (or seems to be?) a saving grace, without which every
| school using Chromebooks could see worms propagating
| rapidly if even one student connected to a compromised
| router at home.
| amluto wrote:
| And, for some utterly and completely absurd reason, CUPS runs
| as a system daemon instead of a highly sandboxed user program.
| bshipp wrote:
| This is the worry. It seems like a really unnecessary
| privilege escalation.
| jeffbee wrote:
| It's because of the frankly idiotic idea of persistent
| print queues. If you want to have this artifact that
| survives a user session, then the print subsystem needs
| super-user abilities.
|
| ChromeOS does away with the whole idea. There are no
| persistent printer queues or jobs. Artifacts of the
| printing subsystem have lifetime tied to the user session.
| funcDropShadow wrote:
| No, persistent print queues can be implemented without
| cups running as super-user.
| throwanem wrote:
| It's a spooler for a printing system that supports concurrent
| job submission, potentially among multiple users. It's going
| to have to achieve serialization _some_ kind of way.
| aftbit wrote:
| Why does it need to run as `root` user and not `cups`?
| throwanem wrote:
| As long as that user can talk to the printers' device
| nodes (and/or the network), it needn't so far as I know.
|
| The original "system daemon vs. user program" dichotomy
| offers a much broader range of interpretations than this,
| though, and it was more the implication of "this can and
| should be an evanescent program invoked by individual
| users, implicitly persisting little or no state between
| invocations" to which I sought to object.
|
| (That said, I take another nearby commenter's point
| regarding the need, and existence, of a more evanescent
| and safer option on systems that will never see more
| printing than one user does two or three times a year.)
| edelbitter wrote:
| On Ubuntu, both. A system daemon with interesting
| interactions with avahi-daemon and colord, and a somewhat
| sandboxed user program, just so Chrome is not overly
| inconvenienced by its snap sandboxing. But wait, there is
| more: The login & lock screen also runs the whole glory of
| GNOME.. to query printer settings. So you can have those
| sweet, sweet "new printer" notifications overlaid while
| inputting your password. Or whatever else "your" printer
| needs to add there.
| johnklos wrote:
| Anyone going to a coffee shoppe and using a public wifi is
| exposing CUPS and can be exploited. Simple minded dismissal
| doesn't help anyone.
| scblock wrote:
| This is a lot less "exciting" than the LOOK AT ME MOM I MADE AN
| EXPLOIT social media posts implied.
| thinkingemote wrote:
| Possibly because the devs reduced the numbers he says: "because
| the devs just can't accept that their code is crap -
| responsible disclosure: no more"
|
| Always kind of worrying to see vulnerability researchers
| justifying bad behaviour because they find a vulnerability in
| code. Maybe it was because his pride was hurt that he threw
| away any ethical behaviour?
| Sohcahtoa82 wrote:
| > vulnerability researchers justifying bad behaviour because
| they find a vulnerability in code
|
| This is an extremely bad faith take that makes me
| irrationally angry to read.
|
| He's not using bad code as a reason to engage in bad
| behavior, he's using _bad responses to responsible
| disclosure_. Read the section under "Personal
| Considerations". It only took him two days to find the
| problem, but _22 days_ to get developers to admit there 's a
| vulnerability, even when shown PoCs.
|
| Imagine finding a vulnerability, responsibly disclosing it,
| being told "meh, not an issue", responding with a PoC showing
| full code execution, and still being told "meh, not an
| issue".
| thinkingemote wrote:
| > Imagine finding a vulnerability, responsibly disclosing
| it, being told "meh, not an issue", responding with a PoC
| showing full code execution, and still being told "meh, not
| an issue".
|
| I would still want to be responsible. I shouldn't get to
| choose to be irresponsible when I have a bad experience.
| Then, naturally when the time is up and the disclosure
| happens according to the timetable, I would be the side
| looking much the better from it. As such behaving as he did
| and justifying it in that way is illogical.
|
| I speculate that maybe the reasons he gave may not be
| entirely the whole story because he would have looked
| better responsibly disclosing, but its important to note
| that he doesn't blame poor code, thank you for the
| correction. And I am speculating for the reasons. Maybe in
| the future I shouldn't.
| Sohcahtoa82 wrote:
| Disagreeing with someone's decisions is not a valid
| justification for misrepresenting their motives.
|
| I agree with you, it's kinda shitty, but I get where he's
| coming from. It's incredibly frustrating to want to
| improve the security of the world, but when developers
| have too much ego and push back against claims of
| vulnerabilities in the face of _proof_ , well...every
| hero either dies or lives long enough to become the
| villain.
|
| I've experienced it first-hand at a previous job. I found
| a buffer overflow in some firmware, and engineering just
| said "Meh, at worst you'll just segfault the device, and
| the user can just reboot". The fix would have literally
| just been a two-line buffer length test that throws a 400
| Bad Request (It was an embedded web server written in C,
| with the vuln being in an XML parsing library), but I had
| to go through the effort of taking that bug and learning
| ARM assembly and return-oriented programming in order to
| create a PoC before engineering decided to fix it.
|
| I suppose I should be happy, though, as that learning
| experience was the cannon that shot me from just being a
| test engineer into getting into AppSec.
| thinkingemote wrote:
| Yes, I can totally empathise with him too. I've behaved
| in emotional ways in with frustration because of code
| (but thankfully not in a public way with certain
| standards of behaviour). Let's hope he can learn from it.
| It's hard to act professional when acting alone and
| outside and against the so-called "real professionals".
|
| Ultimately it's about trust. Perhaps these organisations
| have become too large and uncaring or maybe we have
| become too impatient and frustrated. I don't think anyone
| wants to see researchers not responsibly disclosing as
| well as companies irresponsibly interacting with external
| researchers who _just want to help_. It 's easy to this
| as a path from white to black hat.
| oskarkk wrote:
| Is that an exact quote? He says that he disclosed it now
| because there was a leak and "all vendors that bothered
| participating agreed on today at 20:00 UTC".
|
| https://x.com/evilsocket/status/1839433162168181051
|
| Anyway, I don't like his tone and he's overreacting imo.
| 0x_rs wrote:
| >Is that an exact quote?
|
| It is.
|
| https://x.com/evilsocket/status/1838169889330135132
| beginnings wrote:
| cups isnt installed by default in arch or ubuntu server
|
| ive never even heard of it before now
|
| this is like Geohotz setting up his "hack" for the documentary
| develatio wrote:
| I'm gonna give this a 10/10 meh. Not up to all the hype that was
| created around it.
| whywhywhywhy wrote:
| From DEFCON 1 to "it's absolutely nothing" in 5 hours
| bborud wrote:
| Every time I need to print something on MacOS I am reminded of
| how much I hate printers and any printer related software. I've
| been messing around with computers for 40 years now and
| goddamnit, every decade printers become more of a pain in the
| neck.
| linuxlizard wrote:
| I wrote printer code for 10+ years. I appreciate how hard the
| technical problems are but vendors make it so much worse. I
| loathe printers. Printers peaked with the LaserJet III.
| gruturo wrote:
| IIRC the Laserjet 4 had a much better warm-up time (and lower
| power consumption) by switching to a thin ceramic heating
| element rather than heating half the printer. But yeah
| anything after that is downhill.
| niwtsol wrote:
| do you mind lightly summarizing what technical problems make
| it more difficult? I'm assuming there are all sorts of things
| web-devs never even think about from that world.
| cryptonector wrote:
| Every printer vendor does things differently, every printer
| has different constraints and options? Too many standards?
| op00to wrote:
| I feel like printers are far better now than they were 10 years
| ago. At least on MacOS and iOS, I have no problems finding a
| printer and printing. 10 years ago it was a pain, but now -
| smooth sailing for me. Heck, no driver installs either!
| cp9 wrote:
| printing even works on linux now, thanks to stuff like
| Airprint and the support for it in CUPS
| Jach wrote:
| Yeah something like 10-15 years ago I thought for just the
| simple action of printing a file, it was way easier in
| Ubuntu than Windows, simply because they included a lot of
| drivers in the distro by default, while in Windows land I
| still had to visit the printer manufacturer's website for
| drivers -- or use the included CD! I try to avoid needing
| to do anything more complex than that. (Scanning I've
| always done with a USB stick plugged directly into the
| printer.) Things kind of got worse again in recent years
| with the removal of the standalone GUI for administration
| in favor of a web interface, and various ongoing
| modularization efforts, in theory cups3 will work even
| better and only support IPP/AirPrint:
| https://openprinting.github.io/current/#the-new-
| architecture...
| Joker_vD wrote:
| Funny how the whole FSF movement started in no small part
| because Stallman was irritated with the low quality of printer
| drivers... and how that movement for some (?) reason failed, in
| 40 years, to noticeably improve the quality of printer-related
| software.
| playingalong wrote:
| But at least we got all the byproducts.
| cryptonector wrote:
| Do you remember those portable sh-coded HP JetAdmin printer
| drivers? Are you saying things today are worse than that?
| spookie wrote:
| Of course its CUPS.
|
| Saying it affects all "Linux" systems is just wild.
|
| Imagine even having that thing on your system to begin with.
| doubled112 wrote:
| I'm certainly not regretting disabling avahi and cups-browsed
| on all of my systems long ago.
|
| Do people have printers that move around all the time?
|
| Also, firewalls on desktops and laptops for the win, yet again.
| robinsonb5 wrote:
| > Do people have printers that move around all the time?
|
| I suspect it's not the printers that are moving, but the
| laptops.
| doubled112 wrote:
| Fair, but do people print away from home very often? I've
| never printed anything outside of home since high school,
| but maybe I'm an outlier.
|
| Maybe a better question, would intentionally adding a
| printer at home and a printer at the office be that large a
| barrier?
|
| Maybe we wouldn't even need to drop auto discovery. Maybe
| it could work more like Bluetooth and only broadcast or
| accept connections while it was actively searching.
| yjftsjthsd-h wrote:
| I'm more interested in whether some/all of these work on macOS,
| which is probably a bigger target.
| Tiberium wrote:
| https://github.com/OpenPrinting/cups-
| browsed/issues/36#issue... makes it sounds like most of them
| don't, and even if they do, it's sandboxed.
| outworlder wrote:
| There may be something else for that.
|
| > In part II of this series (date TBD since there's another
| disclosure in process), we'll see how to use these new
| bettercap modules (not yet released) to attack Apple macOS.
| Jach wrote:
| I can't imagine it on a normal server expected to serve public
| internet requests. The way you phrased that though makes me
| wonder for desktop use, is there a non-cups alternative to
| printing on linux these days that's gone under my radar?
| (Please don't say there's a systemd-print...) If nothing else,
| probably another overdue candidate for the energetic rewrite-
| it-in-Rust people.
| andersa wrote:
| So just to make sure I understand correctly, this is a
| nothingburger, right? No important server has a printer attached.
| Any basic firewall would block this traffic.
| rolph wrote:
| botnetting is about exploiting unimportant desktops, to create
| very important servers.
| bshipp wrote:
| I don't know if I would say it's a nothing burger, but i don't
| see how it affects important servers. It might impact a number
| of linux desktops and, if they are linked to important servers,
| provide a backdoor access into important services.
|
| Being able to run arbitrary code in a root account with no
| authentication would seem to be a pretty important security
| breach, although I don't think it's quite the level of danger
| it was built up to be.
| andersa wrote:
| But why would such desktops be exposed to the public internet
| directly?
| bshipp wrote:
| Likely no good reason. But he seemed to have identified
| many many systems that were, inexplicably, exposing port
| 631 to the internet. There is some reason people are doing
| it and, given the number of target systems, it must be some
| sort of default configuration. > "This
| thing is packaged for anything, in some cases it's enabled
| by default, in others it's not, go figure . Full
| disclosure, I've been scanning the entire public internet
| IPv4 ranges several times a day for weeks, sending the UDP
| packet and logging whatever connected back. And I've got
| back connections from hundreds of thousands of devices,
| with peaks of 200-300K concurrent devices. This file
| contains a list of the unique Linux systems affected. Note
| that everything that is not Linux has been filtered out.
| That is why I was getting increasingly alarmed during the
| last few weeks."
| bonzini wrote:
| The 9.9 issue is the foomatic-rip vulnerability; not cups-
| browsed listening on 0.0.0.0. See here:
|
| > LAN: a local attacker can spoof zeroconf / mDNS / DNS-SD
| advertisements (we will talk more about this in the next
| writeup) and achieve the same code path leading to RCE.
| andersa wrote:
| I see. This sounds like a problem for people using public
| wifi...
| bonzini wrote:
| Maybe, maybe not. If I understand correctly, you still
| need to print something to the printer to achieve RCE via
| foomatic-rip.
| sprayk wrote:
| > I had no idea Linux just added anything found on a network
| before the user can even accept or be notified. The more you
| know!
|
| Windows does this too, I believe. At least it did it with a Xerox
| laser printer I bought and the Brother printer at my friend's
| place.
| beginnings wrote:
| my grandparents who are still printing things like its the 90s
| might be at risk, if they have installed CUPS that is
|
| has the president been briefed yet?
| cp9 wrote:
| we should fix this, CUPS is used in a bunch of consumer hardware
|
| it's not a complete disaster like it was implied to be though
| fizlebit wrote:
| It is bad if you print from a Linux laptop that uses WiFi isn't
| it?
| LZ2DMV wrote:
| Only if the machine is directly connected to the internet and
| the malicious packet doesn't hit a firewall somewhere along the
| path.
|
| Most laptops connected to Wi-Fi are indeed connected to an AP
| or a SOHO router that does NAT, so the attacker won't be able
| to directly reach it and this is a requirement for this to
| work.
| bogwog wrote:
| I remember there was some like viral marketing thing some company
| did a while back where they had a website where they had a webcam
| pointed at a printer, and anything printed would go on a conveyer
| belt and fall into a literal dumpster fire. Users could submit
| stuff on their website and see it printed and burned live.
|
| ...anyways, maybe _they_ were vulnerable to this attack at the
| time?
| Dachande663 wrote:
| I suppose the real question now is: did the author give it a 9.9
| out of ignorance or malice/ego?
| rini17 wrote:
| RedHat did, as per the article
| hacker_homie wrote:
| I though this was going to be NetworkManager the way they were
| hyping it up.
| Tiberium wrote:
| Wait, this is a joke, right?
|
| > A remote unauthenticated attacker can silently replace existing
| printers' (or install new ones) IPP urls with a malicious one,
| resulting in arbitrary command execution (on the computer) *when
| a print job is started (from that computer).*
|
| (emphasis mine)
|
| There's no way this is 9.9 when Heartbleed was just 7.5...
|
| EDIT: Wanted to add why I think he has overblown this way too
| much. His original tweet stated "* Unauthenticated RCE vs all
| GNU/Linux systems (plus others)" but as we can see this isn't
| nearly the case as on a lot of distros CUPS only listens on
| loopback or isn't installed at all.
|
| Another point:
|
| > Full disclosure, I've been scanning the entire public internet
| IPv4 ranges several times a day for weeks, sending the UDP packet
| and logging whatever connected back. And I've got back
| connections from hundreds of thousands of devices, with peaks of
| 200-300K concurrent devices
|
| If I'm understanding this correctly, he only found 300 thousand
| open CUPS instances in the whole public IPv4. Remember - the CUPS
| server needs to receive a print job in order for the RCE to
| happen, which I doubt most of these instances will get.
| voytec wrote:
| From the last image in the article:
|
| > 3. Command execution (cups-browsed, cups-filters): 9.9
|
| > CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:H/A:L - CWE-94
| Tiberium wrote:
| Yeah, I guess you're right, for CUPS it might be 9.9. My
| other added points about it being a vastly overblown exploit
| still stand.
| dfc wrote:
| But it seems like User Interaction is required.
| rini17 wrote:
| There are also buffer overflows exploitable without any user
| action. The foomatic vector which requires print job was just
| one easiest to scan and exploit.
| Tiberium wrote:
| Thanks, I missed that. But that still leaves us with only 300
| thousand exploitable instances in the whole public IPv4
| address space. This is nowhere near a universal GNU/Linux
| RCE. Of course it's still a big deal to those affected
| servers, but it's nowhere near even RegreSSHion.
| nullindividual wrote:
| That's nearly as many as Code Red and roughly 100K more
| than SQL Slammer.
| cjbprime wrote:
| Are you sure? E.g. the blog post mentions a one-byte read
| overflow, which is unlikely to be directly exploitable.
| rini17 wrote:
| It also mentions:
|
| > I can tell you that there're other, more easily
| exploitable code paths going on, not just in the discovery
| mechanism - also reported and ignored. To this day they
| have not been acknowledged or patched.
| seanhunter wrote:
| To give the author full credit, they say
|
| > Impact wise I wouldn't classify it as a 9.9, but then again,
| what the hell do I know?
| ezekg wrote:
| > Wait, this is a joke, right?
|
| Not gonna lie, I died laughing at the "Look at me, I'm the
| printer now" meme.
|
| So in a way, it did have a good joke regardless of how you rank
| severity.
| znpy wrote:
| The whole thing looks severely overstated. If i was in bad
| faith i'd say the guy is looking for fame.
|
| I wonder, has the guy tried reproducing the exploit on
| RHEL/Fedora or some other SELinux-protected system? Because
| this looks like the kind of issue that SELinux would protect
| you from: 1. cups likely does not have
| permissions to go and write executable binary files around
| 2. cups likely does not have permissions to go and exec
| binaries without the appropriate labels
|
| If that's the case, this would really be a testament to SELinux
| and the final blow to AppArmor or whatever Canonical is
| shipping nowadays (clearly useless).
|
| I still think that maybe you could steal printing document, but
| i haven't tried. Anyway, i see there's plenty of CUPS-related
| selinux work documented via manpages. Example:
| https://www.systutorials.com/docs/linux/man/8-cupsd_selinux/
| dumpsterdiver wrote:
| Are you suggesting that people should not report remote
| command execution vulnerabilities when such vulnerabilities
| are successfully stopped by SELinux?
|
| Also, why do you think that seeking recognition for your
| efforts a bad thing?
| znpy wrote:
| > Are you suggesting that people should not report remote
| command execution vulnerabilities when such vulnerabilities
| are successfully stopped by SELinux?
|
| No, I'm suggesting that only testing on system shipping
| weak protection systems and poor defaults is misleading.
|
| > Also, why do you think that seeking recognition for your
| efforts a bad thing?
|
| It isn't by default, but it can become a bad thing when you
| overstate the importance of your finding: see my previous
| line in this comment and add the fact that this guy picked
| a cve score of 9.9 where heartbleed had "only" a 7.5 score
| -- but heartbleed affected pretty much _everybody_ in the
| industry.
| outworlder wrote:
| > But here's a screenshot from the VINCE report of the
| initial CVSS scores, including the 9.9, being estimated
| by a RedHat engineer (and also reviewed by another one)
|
| > As I said, I'm not an expert, and I think that the
| initial 9.9 was mostly due to the fact that the RCE is
| trivial to exploit and the package presence so
| widespread. Impact wise I wouldn't classify it as a 9.9,
| but then again, what the hell do I know?
|
| He did _not_ pick the score.
| that_guy_iain wrote:
| > There's no way this is 9.9 when Heartbleed was just 7.5...
|
| There are tons of 10s and for, what are IMO, really silly
| things.
| udev4096 wrote:
| A basic firewall configuration could easily prevent this even if
| you are running the vulnerable version
| chrononaut wrote:
| Queue everyone going to Shodan and investigating how many systems
| have port 631 on UDP open..
| ajdude wrote:
| Do networked printers themselves run CUPS? E.g. a Brother or HP
| laserjet plugged into a LAN.
| aidenn0 wrote:
| vulnerabilities are (mostly?) in cups-browserd rather than
| cups.
| jonjojojon wrote:
| I am slightly confused. If I am using a linux laptop with cups do
| I need to do anything besides update? Is there a sane way to
| print from the linux desktop. I unfortunately need to regularly
| print, and often from public wifi.
| smokel wrote:
| Not an expert, but I guess that simply enabling the firewall
| should avoid most problems related to this vulnerability. In
| Ubuntu, this can be accomplished with: sudo ufw
| enable
| jonjojojon wrote:
| Thank you. I was also able to check that 631 is blocked by
| searching for it in output of sudo ufw show raw.
| LinuxBender wrote:
| Unless you are exposing CUPS to other people on purpose so that
| you act as a print server then block inbound access using a
| local firewall. Your local print jobs should be able to use the
| loopback just fine. Your print spooler would then be talking to
| the IP on your printer and that should also be confined to your
| local network _and may have optional features to further secure
| access._
|
| On a very loosely related note, some enterprise printers have
| optional features to lock down remote access to people that are
| authenticated. Authentication capabilities vary by vendor. This
| is somewhat unrelated to CUPS but probably a good time for
| people to research what their printers can do as printers are a
| great way to steal company secrets.
|
| [Edit] What smokel said. They beat me to it before I refreshed
| the page.
| dfc wrote:
| The original CVSS score on Twitter indicated that user
| interaction was not required. However reading the RCE chain on
| the page says:
|
| _Wait for a print job to be sent to our fake printer for the PPD
| directives, and therefore the command, to be executed._
|
| If Alice never hits print it seems like a print job will never be
| triggered. Am I missing something? I'm not questioning
| evilsocket, I'm trying to check my understanding.
| rini17 wrote:
| There are also buffer overflows which they detected with
| fuzzer, which can be turned into RCE without requiring user
| interaction. But author did not have enough expertise in this
| area to create actual exploit for these.
| cjbprime wrote:
| It is untrue that every buffer overflow can be exploited. We
| won't know whether these can be until someone tries.
| playingalong wrote:
| It depends on the definition of "interaction". AFAIU Alice
| doesn't need to print anything supplied by the attacker. It's
| enough if she prints anything.
| dfc wrote:
| I agree that Alice just needs to print anything but that
| seems like user interaction required. Its also not clear if
| Alice has multiple printers defined does it matter which
| printer she selects?
| kccqzy wrote:
| She needs to print something using the fake printer. Nothing
| happens, IIUC, if Alice chooses to print a document with a
| real printer.
| cjbprime wrote:
| The attack can overwrite the real printer with a fake one.
| kccqzy wrote:
| Where did you see that?
| remram wrote:
| Ctrl+F "replace"
| djordanzachvsd wrote:
| in the middle of the alley
| DanMcInerney wrote:
| Depending on your interpretation of the Scope metric in CVSSv3,
| this is either an 8.8 or a 9.6 CVSS to be more accurate.
|
| In summary, there's a service (CUPS) that is exposed to the LAN
| (0.0.0.0) on at least some desktop flavors of Linux and runs as
| root that is vulnerable to unauth RCE. CUPS is not a default
| service on most of the server-oriented linux machines like Ubuntu
| Server or CentOS, but does appear to start by default on most
| desktop flavors of linux. To trigger the RCE the user on the
| vulnerable linux machine must print a document after being
| exploited.
|
| Evilsocket claims to have had 100's of thousands of callbacks
| showing that despite the fact most of us have probably never
| printed anything from Linux, the impact is enough to create a
| large botnet regardless.
| funcDropShadow wrote:
| Universities are full of people with Linux desktops with public
| IPs and that are printing all the time: papers, their own and
| other's.
| DanMcInerney wrote:
| Yes, good point, university networks are particularly
| vulnerable.
| znpy wrote:
| Having a public ip address doesn't always mean there's no
| firewall in between a pc and the public internet, ideally
| with sensible default rules. It's not 1996.
|
| And sorry if I'm being a bit harsh on this, but this point
| comes up every time when ipv6 is mentioned, by people that
| clearly don't understand the above point.
| guluarte wrote:
| This is nowhere near as severe as the Heartbleed bug.
| udev4096 wrote:
| Github has given it a 4.4 score:
| https://github.com/OpenPrinting/cups/security/advisories/GHS...
| oskarkk wrote:
| That's unrelated to these findings.
| ruuda wrote:
| > That a lot is expected and taken for granted from the security
| researchers by triagers that behave like you have to "prove to be
| worth listening to" while in reality they barely care to process
| and understand what you are saying
|
| The unfortunate reality is that for every well-researched report
| like this one, you get 57 low-effort spam reports that hope to
| extract a bug bounty reward, or get a CVE discovery listed on
| their resume. Especially with the rise of LLMs that kind of spam
| can easily trick you. It's a sad situation, but I don't entirely
| blame developers for being skeptic.
| hypeatei wrote:
| curl developers deal with this exact thing[0] (AI generated
| security reports)
|
| 0: https://daniel.haxx.se/blog/2024/01/02/the-i-in-llm-
| stands-f...
| marcodiego wrote:
| Resuming: 1 - cups-browsed is able to install
| printers automatically (without the requirement of user
| confirmation) by listening to UDP packets on port 631. 2 -
| Attacker uses this "feature" to install a fake printer with a
| custom driver (which is also installed without user confirmation
| and can be downloaded from an arbitrary host) which specifies the
| "command to run" when a print job is sent. 3 - User prints
| something in the fake printer and the "command to run" is
| executed.
| hypeatei wrote:
| > without the requirement of user confirmation
|
| I suppose CUPS was introduced in 1999 so it probably made sense
| then. But why is it still a thing today?
| znpy wrote:
| I would rather expect this kind of change came later, when
| there has been a huge push to make the "linux desktop" more
| user-friendly.
|
| 1999 sounds like the time when people were a bit more
| expected to mess with config file and somehow always had a
| root terminal around. If anything, keep in mind that in 1999
| it was still a rite of passage to have to learn how to write
| the X11 configuration file (what used to be xorg.conf)
| smokel wrote:
| This vulnerability seems to be pretty hard to actually exploit,
| but for those of you who are running Ubuntu on their desktops,
| consider enabling a firewall, which is as easy as:
| sudo ufw enable
|
| Beats me why this is not the default.
| hypeatei wrote:
| Also this: > sudo ufw deny 631 > sudo ufw
| reload
| remram wrote:
| reload is unnecessary if you make changes via the command
| line.
| 0x_rs wrote:
| I don't believe this warranted all the fearmongering even if the
| intention was to get more attention to it and a faster resolution
| process, it's not far from cry wolf. Initial CVE scores are very
| arbitrary. CUPS is a _well-known liability_ when exposed to
| unsafe networks. CVSS scores seem far from perfect. The WebP
| zero-day, a zero-click vulnerability that was being exploited in
| the wild and affecting nearly every user device made in the past
| decade, most of which will never be properly patched from it,
| received an initial 10.0, and decreased to a meager 8.8
| (CVSS:3.1, and would be higher using 4.0).
| cjbprime wrote:
| Why are distros allowing CUPS to listen on all interfaces,
| then?
| LZ2DMV wrote:
| Everyone, please go to your respective data centers, locate your
| rack and unplug the printer from the server.
| computer23 wrote:
| Is there a recommended (best practice) way to nmap scan your
| network for vulnerable machines, just to be safe?
|
| From Red Hat's statement: > Red Hat rates these issues with a
| severity impact of Important. While all versions of RHEL are
| affected, it is important to note that affected packages are not
| vulnerable in their default configuration.
|
| Basically, Red Hat machines aren't vulnerable unless "the cups-
| browsed service has manually been enabled or started."
|
| https://www.redhat.com/en/blog/red-hat-response-openprinting...
| nobody9999 wrote:
| >Is there a recommended (best practice) way to nmap scan your
| network for vulnerable machines, just to be safe?
|
| Perhaps something like this? nmap -sU -p 631
| -P0 [network]/[mask]
|
| Edit: Added [network]/[mask] for completeness.
| cvhc wrote:
| While in this case distros include cups-browsed maybe as a
| feature, I always feel it's a bad thing Ubuntu/Debian (and maybe
| all deb-based distros?) automatically bring up almost all
| services upon installation. This means you can install a package
| and accidentially open another network service that's installed
| as a dependency.
|
| You probably already know exim4 (to be fair it listens to only
| localhost by default, so maybe not a big deal). I just tried to
| install cups-browsed on one of my Debian machine, and it brought
| up two services that listens to 0.0.0.0 (cups-browsed and avahi).
|
| This is not the case for Arch/Gentoo and CentOS-like distros.
| peanut-walrus wrote:
| Tried it out, looks like at least on Debian the filter gets
| invoked with limited user privileges, so not world-ending, but
| still bad. And it does require user interaction, but my gut
| feeling is that this can be bypassed with some cleverness.
|
| However, this is only for this particular exploit. The behaviour
| where cups-browsed automatically downloads and installs printers
| from random untrusted places on the internet is insane,
| especially as it does it for all printers it discovers on the
| local network by default. At minimum anyone on a LAN can cause a
| DoS type attack against all Linux workstations on the same LAN by
| just advertising a few million printers via zeroconf.
___________________________________________________________________
(page generated 2024-09-26 23:00 UTC)