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.
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?
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.
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.
That's nearly as many as Code Red and roughly 100K more than SQL Slammer.
Are you sure? E.g. the blog post mentions a one-byte read overflow, which is unlikely to be directly exploitable.
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.
> 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.
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
But it seems like User Interaction is required.
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.
> 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.
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/
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?
> 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.
> 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.
Anyone exposing CUPS to the internet is living a level of not giving a fuck that CVEs cannot reach.
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.
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.
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.
This is why on public servers I block everything inbound and only allow specific needed services through.
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. ]
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
Why does it even listens in UDP at this day and age?!
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.
DNS is actually UDP/TCP. It’s probably required for receiving unicast messages, if it’s using DNS-SD
To receive multicast messages, probably.
OpenSUSE
But it looks like cups-browsed is only needed on the Internet; locally you only need mDNS.
on popOS I see 0.0.0.0:*
I'm not sure why it deviates from Debian and Ubuntu which its based on though
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.
oh sorry yeah I copied the wrong column. the correct column is `0.0.0.0:631`
I'm pretty sure all major distros configure it to listen locally instead.
cupsd is configured to listen locally, but cups-browsed has to listen on the network to do its job (network printer auto-discovery)
> 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?
Who doesn't block all unneeded ports on an internet facing server or have it behind a firewall of some sort?
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.
Well lots of people crash 600HP cars right after they buy them. If you haven't done your homework, you'll learn quickly.
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.
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.
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.
And, for some utterly and completely absurd reason, CUPS runs as a system daemon instead of a highly sandboxed user program.
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.
Why does it need to run as `root` user and not `cups`?
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.)
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.
This is the worry. It seems like a really unnecessary privilege escalation.
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.
No, persistent print queues can be implemented without cups running as super-user.
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.
It's always funny to me how cybersecurity always seem to attract people with a ... certain sense of ego.
> 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.
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
Or any malicious user on the airport wifi. The compromise will linger until however many weeks later when you decide to print something...
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.
i knew there was a reason i blacklist unsolicited/unauthenticated UDP inbound.
This is a nothing-burger...
> 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.
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.
> 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?
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)
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.
Universities are full of people with Linux desktops with public IPs and that are printing all the time: papers, their own and other's.
Yes, good point, university networks are particularly vulnerable.
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.
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.
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.
It is untrue that every buffer overflow can be exploited. We won't know whether these can be until someone tries.
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.
She needs to print something using the fake printer. Nothing happens, IIUC, if Alice chooses to print a document with a real printer.
The attack can overwrite the real printer with a fake one.
in the middle of the alley
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?
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.
Of course its CUPS.
Saying it affects all "Linux" systems is just wild.
Imagine even having that thing on your system to begin with.
I'm more interested in whether some/all of these work on macOS, which is probably a bigger target.
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.
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.
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.
> Do people have printers that move around all the time?
I suspect it's not the printers that are moving, but the laptops.
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.
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.
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.
But at least we got all the byproducts.
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.
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.
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.
Every printer vendor does things differently, every printer has different constraints and options? Too many standards?
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!
printing even works on linux now, thanks to stuff like Airprint and the support for it in CUPS
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...
Do you remember those portable sh-coded HP JetAdmin printer drivers? Are you saying things today are worse than that?
From DEFCON 1 to “it’s absolutely nothing” in 5 hours
> 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.
This is a lot less "exciting" than the LOOK AT ME MOM I MADE AN EXPLOIT social media posts implied.
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?
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.
> 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".
> 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.
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.
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.
Everyone, please go to your respective data centers, locate your rack and unplug the printer from the server.
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...
>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.
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.
Also this:
> sudo ufw deny 631
> sudo ufw reload
reload is unnecessary if you make changes via the command line.
That's unrelated to these findings.
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.
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?
Queue everyone going to Shodan and investigating how many systems have port 631 on UDP open..
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).
Why are distros allowing CUPS to listen on all interfaces, then?
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.
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.
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
Thank you. I was also able to check that 631 is blocked by searching for it in output of sudo ufw show raw.
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
A basic firewall configuration could easily prevent this even if you are running the vulnerable version
I suppose the real question now is: did the author give it a 9.9 out of ignorance or malice/ego?
RedHat did, as per the article
Do networked printers themselves run CUPS? E.g. a Brother or HP laserjet plugged into a LAN.
vulnerabilities are (mostly?) in cups-browserd rather than cups.
I though this was going to be NetworkManager the way they were hyping it up.
It is bad if you print from a Linux laptop that uses WiFi isn’t it?
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.
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?
This is nowhere near as severe as the Heartbleed bug.
I'm gonna give this a 10/10 meh. Not up to all the hype that was created around it.
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.
botnetting is about exploiting unimportant desktops, to create very important servers.
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.
But why would such desktops be exposed to the public internet directly?
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."
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.
I see. This sounds like a problem for people using public wifi...
Maybe, maybe not. If I understand correctly, you still need to print something to the printer to achieve RCE via foomatic-rip.
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