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.
Gotta wonder how many state actors have been using it for years.
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)
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
I guess I’ll worry about this in 2 weeks then
I’m switching off my internet until this gets fixed holy shit
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
Let’s see if this really affects all Linux systems or if the stars need to align for this to actually be exploitable.
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
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.
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.
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
Seems like he not only deleted the Tweet but also protected his whole account… Very weird…
