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.
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 point is that, if printing works for those people, then we know they have this port open, at least on the university network. So even if it's not exploitable over the internet, it's definitely exploitable from the whole university network, which is almost as good as from the internet.
Just to add a datapoint to the previous comment, my large public US university hands out public IPs to every device on WiFi. If there is a firewall, it doesn't block 8080 or 22.
Yes. It's rather sad that so many people equate NAT with a firewall. Two totally different things. A firewall is good, NAT is annoying. We need to push IPv6 harder.
Uh, Linux desktops have a marketshare of some 4.5% (excluding ChromeOS which isn't affected). Even if most of us don't print (I haven't in the last year and little in the previous five), that will still be a lot of print jobs emitted by Linux hosts.
But real answer is well if you have arbitrary remote code execution you can also read memory, where as heartbleed only read memory... And the reality is same, you were safe from heartbleed if you did not use openssl, you are safe from this if you do not use cups. CVSS score does not take into account if the software is used or not.
I guess a part of the issue is that it was reported as a "9.9 severity vulnerability in Linux" in a bunch of places, which makes it sound incredibly severe, whereas a "9.9 severity vulnerability in CUPS" doesn't
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.
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!
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.
Would you also not block this at the firewall on individual nodes: if you block incoming incoming UDP on port 631 that would at least eliminate one of the two entry points, right?
There is no detail in the article about the other.
The port has to be open on the node for the functionality to work - the whole point is that printers on the same LAN can auto-register. If you don't want that, disabling cups-browsed is much safer than just relying on the firewall. If you do want that, you can't firewall the port at all.
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.
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.
There are a lot of comments on here that assume Linux is only for servers. But just recently there was a post on HN indicating Linux will likely hit 5% desktop share for the first time this year. That's a lot of people on Linux - and a far higher percentage of people using Linux on the desktop will not know anything about this. Sane defaults should not be a luxury. Of course people should know to wear their seatbelts, but seatbelt alarms are still a very good thing.
And this is why Microsoft force pushes updates. I think when Linux desktops become really popular there is quite a worry if the users simply do not update them regularly enough. Or if they are not secured in most ways by default.
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
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.
The purpose of cups-browsed is to listen on a UDP port which allows it to receive broadcasts from legacy cups servers on the local network, whereupon it will talk to cups and configure a local print queue for the printers on the discovered server.
A modern setup doesn't need it and doesn't use it.
Modern cups discovered printers via mDNS and does indeed automatically create temporary destinations for them. This only works with "IPP Everywhere" printers which are 'driverless', i.e., the risk of doing this is limited since there's no printer model-specific software that needs to be run on the local machine to print to a remote printer, as opposed to the legacy protocol implemented (apparently unsafely!) by cups-browsed.
I am very unfamiliar with the protocol, but my impression from a little reading is that the sharing computer broadcasts and the receiver listens. This appears to be for some CUPS specific browsing/discovery protocol rather than mDNS/DNS-SD (cups-browsed supports adding printers discovered that way but depends on avahi to handle the mDNS part).
No, per the article, cups-browsed is used so that a printer can register itself to your system. The printer is the one that initiates a connection to tell your system that it is available at some URL.
As a hacker of more than a decade, none of this really gives me pause. There's still critical sev bugs in tools like Ray, MLflow, H2O, all the MLOps tools used to build these models that are more valuable to hackers than trying to do some kind of roundabout attack through an LLM.
It's relevant if you're doing stuff like AutoGPT and you're exposing that app to the internet to take user commands, but are we really seeing that in the wild? How long, if ever, will me? Ray does remote, unauthenticated command execution and is vulnerable to JS drive-by attacks. I think we're at least a few years away from any of the adversarial ML attacks having any teeth.
It's far more likely that software is improving, but the tools to break it and the number of people willing to invest the time in learning those tools, is increasing. The fact is there are absolutely untold amounts of bugs in every piece of software every written. Finding those bugs, up until the past decade of automation tools to find/exploit them, has been extremely time consuming with few people patient or curious enough to improve their skills in that arena.
Think about the number of programming frameworks that've come out in the past few years. Or GitHub Copilot and ChatGPT which literally write solid code for you. There's no way software has not improved a lot in the past decade but there are WAY more software devs than there are exploit devs or hackers. Similar to the ratio of lions:wildebeest. Way more prey than predators.
Except Microsoft should have world-class internal teams creating fuzzer tools and applying open source tools: you would hope that Microsoft had kept ahead of the hoipolloi.
I'm a professional hacker. Almost all my colleagues got started by asking a simple security question like, "How do I spy on what people are browsing on my home wifi?" Then googling the current tools for it. The next step is writing either a Python script to automate the process or contribute the GitHub of the tool you used to improve it. Less than 10% of my general colleagues (and even lower % for the best colleagues) actually go to school for security. Similar to any other IT work, like getting printers connected to a network or deploying an Active Directory domain across your company. Google it then use the tools and tutorials afforded to you. Basic networking/linux/windows/programming knowledge is usually the prerequisite, but the keyword there is, "basic".
So how do you spy on people on your home wifi. If I run a reverse proxy on my computer and then make the router use it, will chrome detect that it goes through a mitm?
Coalfire | Penetration testers | Denver, Seattle, Atlanta offices
Looking for penetration testers of all skills. We do penetration testing against many fortune 500 companies and I guarantee you won't find a more fun atmosphere in the office. Shoot me a PM if interested or send an email. It can be found on my github account /danhmcinerney.
Hi Dan,
I'm reaching out to you here because I couldn't find your email and I would love to learn more about this opportunity. I am finishing my second master's degree in Information System Security and will be taking certification exams soon in CCNA/CCENT/CCDA/CCNA: Security.
Could you please let me know of more information? I can be reached via email at priscillawang303@gmail.com
Thank you for your time and consideration here!
Warmly,
Priscilla
Hi Dan. I also unable to find your email on github.
Im an ethical hacker and pentester from Russia, worked many years for government and now looking for a job. Please can you sent more info to me randtgn@gmail.com, i also will provide more details about me :)
Coalfire | Denver, Seattle, Atlanta | Full-time | Onsite
Coalfire is a security company who is always looking for skilled penetration testers. We have positions from junior penetration tester up to senior based on experience. We absolutely hire people with no previous professional security experience as long as you prove that you have the passion for it through previous self-taught experience. Our clients include Fortune 50s and travel is maybe 20% of the deal. We do web application hacking, network hacking, even full-blown red team operations where essentially anything goes. You should see our lock picking cabinet.
You have any interest in people very skilled in parkour for physical security tests? I'm currently at a fulltime job I'm not planning on leaving soon, but it'd be interesting to talk/I can refer you some people. Email me - email is in my profile.
More details on the development and challenges can be found in the blog.