New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
The scenario you described just happened fairly recently on Windows - CVE-2024-38063
People who had IPv6 disabled were unaffected.
Preview of @yoursunny if your prophecy ends up a reality
My wife just asked me why I was laughing and choking on my drink.
FreeBSD != *BSD
Well... as long as it only affects linux family and not BSD-like OSes, it's clear that the issue is somewhere in the kernel. Maybe a new gblic exploit? Those never end...
I guess it can also be related to the network stack; else the attacker would need some kind of local access to the host.
So if not network-related, guess hosts should be safe if you only allow the absolute necessary ports to reach internet and do some amount on filter on those as well.
If kernel-related, as long as you don't give the attacker a local user/ftp access, should be safe in theory. Kinda bad for shared hosting machines... but those are already a disaster waiting to happen sooner or later.
I doubt it's some service exploit (eg. apache) as it could be exploited also on other OSes.
It does say "GNU/Linux" (which usually refers to a GNU userspace), so maybe not kernel related (as that would also affect Android and other networking devices).
glibc could be an option, or maybe systemd?
Hmm... it also says "for the last 20 years"... If that's somewhat accurate then maybe not glibc (more than 20 years) or systemd (too recent).
Or its all a hoax. As far as i can tell, we have yet to see any official confirmation.
The only thing that we know for sure is someone made some claims and showed a few screenshots that have yet to be authenticated.
That said, speculation seems to be going quite wild
That's also quite a possibility.
No, of course not. If Redhat publicly announced that they were working on fixing a 9.9, every threat actor in the world would drop everything else and try to get their hands on this (supposedly) God mode vulnerability.
It's wise to be sceptical, but in this case speculation is going wild because the researcher is a well known tool developer and he isn't going to blow up his reputation creating a Twitter drama.
For those who don't know his work, these are a couple of his projects:
https://www.bettercap.org/
https://pwnagotchi.ai/
He says he'll release his research on October 6th, but he's since dropped this list of affected versions: https://pastebin.com/7zzFzxCN
In case the Paste in gets deleted, it appears to list all(?) versions from Linux 2.6.32-042stab120.18 through to Linux 6.9.9cxleak+
also up to Linux 6.11.0-8-generic
So it's a kernel bug then, and not anything in userspace? So Android could also be affected?
If this paste is true I would diff first appearance Linux 2.6.32-042stab120.18 and it's parent tag. And then hammer all new codes in between tags.
That may actually be a very smart move.
Confusing. You expressed a desire that DA comes back to *BSD while quoting the phrase "OpenBSD". I doubted DA was ever available on OpenBSD, and you inform me that FreeBSD is not part of the BSD world.
I'm sure there's some sort of point in there somewhere.
We're probably reading it too literally, but it's possible that glibc could have introduced a bug in a version 20 years ago.
I feel so vulnerable, so exposed, so naked...
That version might not necessarily be the first one with the vulnerability, but just one that has been tested.
2.6.32 was 2009, so not "last 20 years". If we're being literal, 2.6.8 was Aug 2004.
Here's what was new in 2.6.32.
This is supposedly a remote code exploit.
(Does Bluetooth count for an RCE?)
This is a tweet from the same person a few days before the drama tweets:
"the next series of blog posts and bettercap features will make many red teamers happy for years to come ... i've found a relatively unexplored attack surface (LAN context) that can be attacked to do nasty stuff and probably can't be fixed"
A few hours later they tweeted this image, which they've since confirmed is a "VINCE" report, (implying the potentially affected vendors, as assessed by the coordinating CERT):
https://imgur.com/a/2YafXYF
Frankly, to me that looks more like the mother of drama signals and that the guy has somewhat cooled off before the posts in OP.
And oh look! FreeBSD is listed too! (which makes the drama even less credible).
IF however, this turned out to be a bowl with at least some meat on the bones in the soup that guy will make a major career step.
My guess though is that there's just watery soup in the bowl with plenty of "potentially", "could", "might" etc. (and some angry people at some intelligence agencies ...)
I am with @jsg on this. I am also a bit suspicious. Until all this issue is made public, it remains a big "IF".
I suspect you're underestimating the current state of the guy's career. I saw him presenting new exploit techniques on the main stage of a big InfoSec conference back in 2016.
Sure it does, but it will then require specific hardware setup and drastically reduce impacted systems count.
Yep. Everything that does not require local proximity to the target is "remote". Note that I did not say "local access", because (a) that would require yet another definition (what is 'access'?), and (b) that would exclude attacks that are not remote but neither "local access".
"direct" probably would be a better term than 'local' (access) for diverse reasons (usually "grey zones") like e.g. is it really "remote access" if a system is accessed from the next office on the floor?
Also diverse attacks via e.g. power monitoring and the likes are "local" but not "direct" in that the goal is the system but not the way.
In security we tend to think that a remote attack vectors are aiming at "normal" ways to gain access (but of course using vulnerabilities in those ways, e.g. networking) while direct vectors require local proximity but are not necessarily using "common" ways (e.g. keyboard) and often focus on getting information rather than attacking (which would be the next step, using the gathered info).
So, judging in a hard way an attack via bluetooth could quite well be classified as not remote, depending on how tight one defines "proximity" (which e.g. for investigations is of importance).
Unfortunately I'm really bad at graphics, colour fluff, "UX" BS, and do not have time to waste. But trust me, if that were not the case I could show you "proof!!!" of RedHat (or anyone of your choice) flagging your toaster model as RCE level 11 as well as your right front tire having a kernel vuln (level 9.7) *g
I am not sure. Exploited, yes, privileges over the kernel, not always.
Except there are heaps of minor versions skipped. Which is strange. There is too many in that list for those to be manually tested, but strange gaps for anything else.
Some more clues from slashdot
To me, that sounds like an excellent way to sully your reputation in a hurry.
Chicken little, anyone?
If it was libc related, I wouldn't expect there to be vulnerable kernel versions - since the distributions select the libc version (and some actually run non-glibc, e.g. musl). The kernel doesn't use libc at all.
So it must be after the network stack? And unrelated to any common software running on normally open ports.
Not enabling a firewall by default comes from Debian (where the "firewall" was typically selected by the user) - security through simplicity. I have a theory that security guys like the complexity of selinux and friends because it gives them a job. 🤣
Well... that's insane... I can see why there was dev push-back. I'm just thinking back to the Immutable Laws of Security.
If an attack requires a human to do something they wouldn't normally do... I wouldn't call that RCE... Same as asking a user to open a PDF, that's not RCE...
I think it’s more like, "had the victim taken a specific implausible action before the attack” at some point in time, and not necessarily as part of the attack. But you never know.
I mean, yeah, I guess? How close is that to, "if the user used a bad password" or "if the user enabled export ciphers"? (basically, a configuration problem)
I remember an arbitrary code execution attack that I was building a defense for (we were like Crowdstrike, but we didn't break people's kernels because we operated in user-land). It was against a popular framework, but it only worked if ops didn't follow the docs and set a signing key (without configuration, it operated in test mode). Is that a RCE? I don't know, the line really starts to get fuzzy. Security experts would say yes, but devs/ops would say no.
IMO, RCE should only be called RCE if the RCE is possible with the recommended configuration.
All that said, I think I mostly just dislike the sensationalism.