Let’s see if this really affects all Linux systems or if the stars need to align for this to actually be exploitable.
I still remember hearing about a Ring 0 exploit in Windows (I may be misremembering, though) that required Ring 0 access. I think if an attacker has access to Ring 0, you’re already screwed anyway.
I agree, all this attention grabbing sound to me as if this is actually not a big deal. But we will see i guess.
A 9.9 is pretty bad no matter what. They wouldn’t rank it almost a 10 if it was some obscure bug that is very hard to exploit.
With that being said it is hard to know without details
Nitter link not working. What’s the jist?
This link should be working.
Quoting from the OP tweet:
* Unauthenticated RCE vs all GNU/Linux systems (plus others) disclosed 3 weeks ago.
* Full disclosure happening in less than 2 weeks (as agreed with devs).
* Still no CVE assigned (there should be at least 3, possibly 4, ideally 6).
* Still no working fix.
* Canonical, RedHat and others have confirmed the severity, a 9.9, check screenshot.
* Devs are still arguing about whether or not some of the issues have a security impact.I’ve spent the last 3 weeks of my sabbatical working full time on this research, reporting, coordination and so on with the sole purpose of helping and pretty much only got patronized because the devs just can’t accept that their code is crap - responsible disclosure: no more.
Seems like he not only deleted the Tweet but also protected his whole account… Very weird…
A 9.9!? Holy shit.
The real question what is the exploitability score
I’ve noticed Canonical replaced their score breakdown with an ad for their paid services.
That probably means this is closer to a publicity stunt. I’ll just wait until there is more information.
No, I mean for every USN
I can’t think of anything except the kernel that is genuinely obligatory on all Linux systems, including embedded. Not glibc (musl). Not udev (mdev). Not systemd (OpenRC/runit/etc). My guess is that this is another exploit of something the reporter hasn’t realized isn’t mandatory because they’re not familiar with non-mainstream distros. I suppose it could be a kernel issue that Android has specifically patched, but if that’s it it’ll be fixed in short order.
In other words, not exactly holding my breath.
If it’s only GNU Linux - and not regular Linux - then we know it’s not the Linux where the issue occurs. ;-)
(Just analyzing what’s said. It’s probably all linuxes if it’s not a glibc issue)
It says GNU/Linux but also says “and others” which could mean anything. eg doesnt specify if something like Alpine would be affected—is that “and others”?
In any case, I’ll wait 2 weeks and find out.
10/10 that poor bloke from Intel who copy-pasted code without understanding it (and got an earful for it) had buffer overflow bugs in his bit of plagiarized oeuvre
Since this affects Linux and others, I’m guessing this is about OpenSSH. But I’m not very certain. Just can’t think of another candidate.
But holy sh, if your software has been running on everything for the last 20 years
This doesn’t sound like glibc as someone in the thread guessed.
Could be quite a few different things.
Could be the kernel itself, gnupg, openSSH or even bash.
But we won’t know for sure, until it’s publically disclosed.
Could be the kernel itself
Wouldn’t make sense to me because the thread says GNU/Linux and others, though this could relate to Android or distros not using any GNU.
gnupg
Usually not exposed to the network though, but it’s generally a mess so wouldn’t be too surprising
Another candidate I have in mind is ntpd, but again that is usually not easily accessible from outside and not used everywhere, as stuff like systemd-timesyncd exists.
Just want to stress that I’m not sure about it being OpenSSH, it was more supposed to be a fun guess than a certain prediction
I guess I’ll worry about this in 2 weeks then
More important question is - how this nitter instance is still working!!
I believe if the instance is still up then it will still work up until a daily limit is reached. Most of them appear to be broken because the limit is fairly low.
Looks like its out there now:
https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/
Short version (correct me if I’m wrong):
If you have CUPS service cups-browsed on your machine and you for some reason exposed that to the internet (port 631), you are about to get pwned.
EDIT: It also requires the user to print to the malicious fake printer.
Yeah, what a disappointment. This guy brought shame to the security community because he was salty that his vulnerability didn’t get the attention it “deserved”.
Disappointment? Only if you mean the person that came up with FoomaticRIP.
For those who did not read the entire thing, it’s a so called “filter” that converts the document before it’s sent to certain nasty types of printers. Except it’s not executed on the print server. The unauthenticated print server can just ask a client to run it on their side. And it’s designed to be able to execute ANY command.
I’m switching off my internet until this gets fixed holy shit
We can see you totally didn’t do that. Also how would you even get the update?
That was a bit sarcastic, but my Linux servers are indeed disconnected. I’d create my personal mirror (preferably on BSD and update from there). Now that the cat is out of the bag though, I feel stupid. Really, for CUPS??? Are you kidding me???
Gotta wonder how many state actors have been using it for years.
