This vulnerability, hidden within the netfilter: nf_tables component, allows local attackers to escalate their privileges and potentially deploy ransomware, which could severely disrupt enterprise systems worldwide.
CISA Warns of Linux Kernel Use-After-Free Vulnerability Exploited in Attacks to Deploy Ransomware
https://cybersecuritynews.com/linux-kernel-use-after-free-vulnerability-exploited/
93 Comments
turdas@suppo.fi · 90 pts · 302d
This only affects positively ancient kernels:
somerandomperson@lemmy.dbzer0.com · 32 pts · 302d
fuck my phone running android is vulnerable
unwillingsomnambulist@midwest.social · 16 pts · 301d
If I’m not mistaken, RHEL9 and equivalents are on 5.15. That’s a pretty big blast radius.
turdas@suppo.fi · 8 pts · 301d
They will probably have a version newer than 5.15.149.
unwillingsomnambulist@midwest.social · 1 pts · 300d
AliasAKA is correct, it’s actually 5.14, not 5.15 like I thought.
Brosplosion@lemmy.zip · 4 pts · 300d
RHEL is on 5.15 in spirit only. They backport tons of patches to the point that 5.15 modules don't build against it
AliasAKA@lemmy.world · 3 pts · 300d
I think RHEL9 uses 5.14 as base
unwillingsomnambulist@midwest.social · 1 pts · 300d
You’re right, it’s 5.14 not 5.15 like I thought. I’m spending most of my time im Debian these days though, so I’m glad I wasn’t too far off.
anamethatisnt@sopuli.xyz · 4 pts · 302d
Debian Bookworm (Debian 12/oldstable) would be affected then, I think?
turdas@suppo.fi · 9 pts · 302d
It looks to be on 6.1.153 currently which is much newer than 6.1.76.
anamethatisnt@sopuli.xyz · 1 pts · 301d
Sweet, cheers for checking - I just remembered it being on 6.1.?
Lost_My_Mind@lemmy.world · 2 pts · 302d
How would I know what kernal I have?
turdas@suppo.fi · 16 pts · 302d
With the
uname -acommandBCsven@lemmy.ca · 30 pts · 302d
Local attacker? So on your LAN
henfredemars@infosec.pub · 26 pts · 302d
You need to be able to run code on the system that has the bug. The bug is in the netfilter component, in how it's managed on that system, not in the actual traffic flows.
BCsven@lemmy.ca · 8 pts · 302d
So a non issue unless somebody has physical access to the machine?
who@feddit.org · 22 pts · 302d
Unfortunately, it's not that simple, because attacks often involve "exploit chains". In this case, an attacker would use a different vulnerability to gain code execution capability, and then use that capability to exploit this vulnerability.
Update your systems, folks.
BCsven@lemmy.ca · 1 pts · 301d
Understood
bookmeat@lemmynsfw.com · 8 pts · 302d
No. They just have to be able to place exploit code onto your machine and have it run.
BCsven@lemmy.ca · -2 pts · 302d
If they can place exploit code on my machine, I think its already game over, regardless of that bug
CriticalMiss@lemmy.world · 8 pts · 302d
Not necessarily, if you follow proper hosting etiquette, then even if they break in they should only be a standard user and have no access to the rest of your system. But most self hosters just run everything as root as it’s less of a hassle.
BCsven@lemmy.ca · 1 pts · 301d
I guess I was thinking of the many Linux users I have encountered that sets same user and root password, or has sudo as passwordless. SMH
henfredemars@infosec.pub · 1 pts · 301d
Not directly, but as other comment has mentioned, it reduces the overall security posture because it could be combined with other flaws known and unknown.
BCsven@lemmy.ca · 1 pts · 301d
Yeah, less vectors are better
Evil_Shrubbery@thelemmy.club · 4 pts · 301d
The (ssh) call it coming from inside the 127.0.0.1!!
(Scoot over, I need the keeb.)
Treczoks@lemmy.world · 29 pts · 301d
For exploiting a privilege escalation the attacker must be able to run their own code on your machine. If you let them do such things, you already have more than enough security problems in the first place.
okamiueru@lemmy.world · 13 pts · 301d
Except for supply chain attacks. You get a foot in the door, and open the rest with impunity
Treczoks@lemmy.world · 1 pts · 300d
Yes, but still a privilege elevation bug is still less risky than a remote execution one.
JackbyDev@programming.dev · 4 pts · 300d
They're replying to the victim blaming mentality of "if you let them then you have bigger problems" in your comment. Not your point about it being less dangerous than remote execution.
qweertz@programming.dev · 19 pts · 302d
And that kids, is why we are pushing for Rust in the Kernel
onlinepersona@programming.dev · 22 pts · 302d
But... You dont understand, Rust is the devil! If Rust were made the kernel's main language it would terrible because that would mean change 😭😭😭
Zangoose@lemmy.world · 7 pts · 301d
But then the kernel wouldn't be free! Free as in 'use-after-free'!
(/s in case it wasn't obvious)
Shanmugha@lemmy.world · 1 pts · 302d
Magical pills do not exist. Better start pushing old fuckers incapable of learning out of the project (yeah, I don't like this kind of treatment of Rust just because it is not C either)
Quazatron@lemmy.world · 21 pts · 302d
Old fuckers exist to protect young fuckers from throwing out the baby with the bath water.
Quazatron@lemmy.world · 7 pts · 301d
I'm referring to the ageism implied in the statement, I don't care about C vs Rust any more than I care about vi vs emacs or KDE vs Gnome.
Old fuckers have experience, they have seen many next big things come and go, that's why they seem slow to adopt new stuff. Of course this annoys new fuckers a lot, as they want to play with their new shiny toys now.
Patience is a virtue, young grasshopper.
Shanmugha@lemmy.world · 4 pts · 302d
Ooh, so "get out with this Rust, I ain't gonna think about when writing my code" is protecting a baby now?
ZILtoid1991@lemmy.world · -1 pts · 302d
Okay, then why we need to use a language that has more in common with OCaml? What about using a better C instead?
ayyy@sh.itjust.works · 2 pts · 301d
Such as?
ZILtoid1991@lemmy.world · 3 pts · 301d
https://dlang.org/
This language was there for a lot longer than Rust, and is not "OCaml, but with curly braces for scopes".
dreadbeef@lemmy.dbzer0.com · 1 pts · 300d
no one uses d
ZILtoid1991@lemmy.world · 1 pts · 300d
It's never too late to start!
dreadbeef@lemmy.dbzer0.com · 1 pts · 300d
let me clarify: no employer uses d. I use d. I am a nobody
corsicanguppy@lemmy.ca · -2 pts · 302d
Yay! Pick an arbitrary solution to a problem just because it's different and shiny! The shine will fix it!
possiblylinux127@lemmy.zip · -11 pts · 302d
Rust would not of fixed this
Rust isn't magical
dragonfly4933@lemmy.dbzer0.com · 30 pts · 302d
Explain how a use after free could occur in safe rust, because to my knowledge, that is exactly the kind of thing rust does protect against.
caseyweederman@lemmy.ca · 6 pts · 302d
Duh, by wrapping it in an
unsafeblock.Boom.
calcopiritus@lemmy.world · 2 pts · 300d
Easy. Do some specific incantation that barely looks like it follows rust syntax that is specifically made to exploit a bug in the rust compiler.
Zangoose@lemmy.world · 6 pts · 301d
Do you know what a use-after-free bug is? Rust was literally designed to make this type of memory bug impossible.
Noja@sopuli.xyz · 5 pts · 301d
You never say "would not of". It's "would not have".
Rust would have prevented this, because the borrow checker prevents use-after-free vulnerabilites.
just_another_person@lemmy.world · -13 pts · 302d
Lol. You have no idea what you are talking about about here 😂
qweertz@programming.dev · 21 pts · 302d
Granted, I was mostly shit posting. But in all seriousness: wouldn't Rust prevent that kind of exploit by inherent design?
https://stanford-cs242.github.io/f18/lectures/05-1-rust-memory-safety.html
henfredemars@infosec.pub · 8 pts · 302d
Yes, that's right. You cannot have a UAF situation unless you're using unsafe "escape hatch" tools.
just_another_person@lemmy.world · -3 pts · 302d
Again... IMPROBABLE
calcopiritus@lemmy.world · 3 pts · 300d
I've only seen it once. And it was made specifically to trigger a compiler bug. It barely looked like rust code.
Now tell me how someone will introduce such a bug by accident. Winning the lottery 10000 times in a row with the same number isn't impossible either. But we are engineers, not pure math pedantics. 0.000000000000001% probability for something that happens with less frequency than once per second is impossible.
turdas@suppo.fi · 5 pts · 302d
C++ would also solve this for the same reason!!
Miaou@jlai.lu · 6 pts · 302d
If this is a joke, I don't get it
turdas@suppo.fi · 1 pts · 301d
It's not a joke. What was described above is pretty much C++'s RAII pattern, which Rust evangelists love to present as a revolutionary Rust invention. Used with smart pointers, it will help avoid use-after-frees. What it doesn't avoid is null pointer exceptions (you can
std::movea unique_ptr and still access it, it'll just be nullptr), but those will typically "just" be a crash rather than a gaping security hole.That is not to say Rust doesn't have its own innovations on top of that (notably that the compiler stringently enforces this pattern), and C++ does give you many more ways to break the rules and shoot yourself in the foot than Rust does.
sp3ctr4l@lemmy.dbzer0.com · 5 pts · 301d
Your second half there is the whole point.
Being memory unsafe in C++ is can occur by accident.
Being memory unsafe in Rust... essentiallly requires consistent intent.
When coming up with guidelines for an emgineering procesd that can go catastrophically wrong... do you use a stricter ruleset, or a less strict one?
That's basically the safety argument.
turdas@suppo.fi · -1 pts · 301d
If you follow modern C++ best practices, memory unsafety will not happen by accident. The dodgy stuff in modern, idiomatic C++ is immediately obvious.
henfredemars@infosec.pub · 1 pts · 301d
I think the idea is that it’s easier to manage your resources in C++ if you write your code using RAII. Linux is mainly C, not C++, which makes resource management a little bit more manual.
Rust however categorically tries to stop these problems from happening in an even stronger way. You can still write bad code in any language, but it’s supposed to be a lot more difficult to get memory corruption.
possiblylinux127@lemmy.zip · 1 pts · 302d
Rust still has memory related bugs
dragonfly4933@lemmy.dbzer0.com · 7 pts · 302d
This is correct, but not what most people think. For example, memory leaks could be considered bugs and it is easy to leak memory memory in safe rust on purpose.
Memory leaks are usually not disastrous for security, mostly an issue for availability, sometimes.
Zangoose@lemmy.world · 2 pts · 301d
I think a lot of the confusion comes from the ambiguity of the phrase "memory leak." Rust is designed around preventing insecure memory access (accessing out of bounds for an array, use-after-free, etc.) and devs call that a memory leak. But another form of memory leak is just not freeing up memory when its no longer needed (e.g. continuously pushing a bunch of things to a global vector and never clearing it). That is more of a fundamental program design issue that rust can't do anything about. (and really, neither could any turing complete language)
just_another_person@lemmy.world · -5 pts · 302d
Improbable. Everything has bugs that surface. See my other link, or look yourself. There have been plenty of security fixes for Rust. It's not bulletproof, just like anything else, just less likely specifically for certain memory attacks to be vectors.
arcterus@piefed.blahaj.zone · 9 pts · 302d
This is a worthless statement. Rust is designed to help reduce the number of bugs. No one thinks Rust will completely eliminate all bugs. Your argument about fixes in the compiler or standard library or whatever applies to C as well.
The link you posted says nothing about Rust software having bugs, it's about malware written in Rust exploiting bugs in other software.
ethancedwards8@programming.dev · 10 pts · 302d
Clearly you have no idea. Rust makes this kind of bug impossible.
possiblylinux127@lemmy.zip · -4 pts · 302d
It is still possible to have security vulnerabilities in Rust
Zangoose@lemmy.world · 3 pts · 301d
'Use-after-free' bugs are a specific type of memory access bug that Rust was designed around preventing. It literally refers to trying to access a block of memory after it has already been freed by the memory allocator. Unless you go out of your way to use the "unsafe" keyword in rust (which in most cases, you shouldn't) then this type of bug is not possible.
caseyweederman@lemmy.ca · 2 pts · 302d
Utopia or nothing!
ayyy@sh.itjust.works · 1 pts · 301d
Nobody claimed otherwise.
qweertz@programming.dev · 1 pts · 301d
That's not what's at issue her LOL
just_another_person@lemmy.world · -9 pts · 302d
WOW. No, it would make it improbable. It's not like there can't be zero-days for Rust, bud. This particular attack vector deals with memory handling, and sure, Rust's main feature is memory security and management. Doesn't mean there aren't bugs to exploit there.
https://linuxsecurity.com/features/rise-of-rust-based-malware
arcterus@piefed.blahaj.zone · 13 pts · 302d
Did you even read the article you posted? This is about malware written in Rust being harder to analyze (or notice), not software written in Rust having vulnerabilities...
aubeynarf@lemmynsfw.com · 5 pts · 302d
just_another_person@lemmy.world · -2 pts · 302d
🤦 It's not necessarily about bugs in Rust-lang, though you can lookup CVEs if you want. The point is that ANY software, by default, will have bugs and exploits. Doesn't matter if it's Rust or C. You can exploit at the core, or at implementation. It's just matter of time and effort, as they say.
Just flat out saying Rust, or software written in Rust is be default is secure, is a fool's assertion. Sure it's LESS LIKELY to have a memory exploit, but that's where that assertion ends.
aubeynarf@lemmynsfw.com · 1 pts · 301d
Lost_My_Mind@lemmy.world · 1 pts · 302d
Neither do I. What's Rust in this context?
AMoistGrandpa@lemmy.ca · 5 pts · 301d
Rust is a programming language which was designed to be memory safe without any of the overhead caused by traditional memory safety techniques employed by existing languages (namely, garbage collection and reference counting). It does this by shifting the memory management from happening at runtime to happening at compile time. The compiler forces the programmer to follow certain rules to ensure that their program can be proven to be free of errors such as use-after-frees and double-frees. Because of this design philosophy, Rust is a good fit as a replacement for C, because it can do everything that C can while ensuring the programmer doesn't make any mistakes with regard to memory management.
NutinButNet@hilariouschaos.com · 2 pts · 302d
Rust is a programming language. Not to be confused with the video game.
A_Chilean_Cyborg@feddit.cl · 2 pts · 302d
Is that videogame written in that programming language?
Serinus@lemmy.world · 1 pts · 302d
Nope. Rust is a low level language.
A_Chilean_Cyborg@feddit.cl · 0 pts · 301d
c/woooosh
ivanafterall@lemmy.world · 15 pts · 301d
Feeling pret-ty smug about my Windows 10 machine rn ngl
Frenchgeek@lemmy.ml · 19 pts · 301d
Your Windows 10 machine? Microsoft disagree.
prole@lemmy.blahaj.zone · 8 pts · 301d
Lol because Windows has never been exploited
ivanafterall@lemmy.world · 0 pts · 301d
Name literally one time!?
prole@lemmy.blahaj.zone · 12 pts · 301d
This is a joke right
ayyy@sh.itjust.works · 8 pts · 301d
I hacked it. The screen said “It is now safe to turn off your computer.” but I left it on instead.
Evil_Shrubbery@thelemmy.club · 5 pts · 301d
That one time that Clippy started peeling off it's flesh whilst chanting in reversed Latin and also wasn't in the computer anymore.
(This was after I let it play that Flash with the Badger song for two weeks so I kinda understand what happened.)
ScoffingLizard@lemmy.dbzer0.com · 5 pts · 300d
I read: Microsoft started to feel threatened and paid black hats to exploit vulnerabilities in wares that people have recently learned are far superior to their goddamned surveillance garbage.