It’s a privilege escalation.
The vulnerability, tracked as CVE-2024-1086 and carrying a severity rating of 7.8 out of a possible 10, allows people who have already gained a foothold inside an affected system to escalate their system privileges. It’s the result of a use-after-free error, a class of vulnerability that occurs in software written in the C and C++ languages when a process continues to access a memory location after it has been freed or deallocated. Use-after-free vulnerabilities can result in remote code or privilege escalation.
rust mentioned, lets goo
Blazingly fast 🚀
a use-after-free error, a class of vulnerability that occurs in software written in the C and C++ languages when a process continues to access a memory location after it has been freed or deallocated.
Immediately I noticed how when Teslas can’t drive themselves we also blame the car and not the driver.
Weak. Blame the driver.
Outfits that haven’t installed patches since February are getting popped in May by a vuln that was published in January.
Outfits? What does it mean in this context?
Organisations
Ahh, thank you
Yet another security issue that Rust would solve.
Oh, we heard, Rust is the greatest invention since sliced bread. We heard it already. Like 65534 times.
Like 65534 times.
So close to full 16-bit max. So close…
Yeah we only need 2 brainRusts more to start seeing some fun.
Yeah I figured he was going purposely for a memory overflow
I wonder how many folks are just refusing to use Rust to spite the Rust Evangelism Strike Team.
Rustaceans 🤝 Vegans
I wish there was a synonym for “evangelism” that began with a “u”.
Aviation, Health, Space and Car industry have only 3 certified languages that they use. Ada, C and C++. Ada is dying because there are way less young engineers who want to invest their future learning it. Then there is C and C++ but they dont offer memory safety and its really hard to master and its really hard and long (thats what she said) to certify the code when being audited for safety by a tier company.
Rust solves by default (no need to review) like 2/3 of the standard requirements those industries have and are that found in C and C++. Rust will soon be approved in this group by the car industry.
Im not a rust fan, but I have 3 things to say about rust.
- Its fun to program like C++ having the peace of mind knowing the compiler is there helping.
- You dont feel like youre defusing a bomb like when writing C.
- Even though its a fun language to write, its also really hard to master, itd say 2 years to be really proficient with it. There is just so much knowledge.
Ada SPARK is not dying at all, it’s growing. It is used where formal proof is required like and Rust is nowhere near that!
- You dont feel like youre defusing a bomb like when writing C.
Whoa, Skippy. It’s not saving the world, it’s just coding properly.
I hate it when people talk about new technologies 🤬
Same. We should head back to ICQ!
eh, still beats Discord as far as I’m concerned
Yeah, but no one will hop on irc or mumble to hang out these days.
There are still slight advantages to C that probably will make some devs stick to it in specific cases
But this isn’t one of them
Serious question, how would using rust avoid this? Rust still has reference types in the background, right? Still has a way to put stuff on the heap too? Those are the only 2 requirements for reusing memory bugs
This is a use-after-free, which should be impossible in safe Rust due to the borrow checker. The only way for this to happen would be incorrect unsafe code (still possible, but dramatically reduced code surface to worry about) or a compiler bug. To allocate heap space in safe Rust, you have to use types provided by the language like
Box,Rc,Vec, etc. To free that space (in Rust terminology, dropping it by usingdrop()or letting it go out of scope) you must be the owner of it and there may be current borrows (i.e. no references may exist). Once the variable isdroped, the variable is dead so accessing it is a compiler error, and the compiler/std handles freeing the memory.There’s some extra semantics to some of that but that’s pretty much it. These kind of memory bugs are basically Rust’s raison d’etre - it’s been carefully designed to make most memory bugs impossible without using
unsafe. If you’d like more information I’d be happy to provide!The way I understand it, it is a bug in C implementation of free() that causes it to do something weird when you call it twice on the same memory. Maybe In Rust you can never call free twice, so you would never come across this bug. But, also Rust probably doesn’t have the same bug.
My point is it seems it is a bug in the underlying implementation of free(), not to be caught by the compiler, and can’t Rust have such errors no matter its superior design?
The way that rust attempts to prevent this class of error is not by making an implementation of free that is safe to call twice, but by making the compiler refuse to compile programs where free could be called twice on a pointer.
Anyway, use after free doesn’t depend on a double free. It just means that the program frees memory but keeps the pointer (which now points at memory that could contain unrelated data at some future point in time) and if someone trying to exploit the program finds a way to induce the program to read or write to that memory they may be able to access data they are not expected to, or write data to be used by a different part of the program that they shouldn’t be able to
Yet another problem that actually updating your shit - which is trivially easy on enterprise Linux - would fix.
It’s part of the 95% of problems solved by actually updating your enterprise Linux host.
I don’t think it’s realistic to expect a rewrite of code that works. Maybe over time we can start implementing pieces in safer languages.
It’s realistic if security is a priority.
Any software can have security issues, including ones written in rust. Just because C/C++ allows one to shoot oneself in the foot doesn’t mean it’s something that’s commonly allowed by anyone with any skill, it’s just a bug like anything else. I swear, people advocating rust believe that it’s something intrinsic in C/C++ that allows such a thing regardless of what a developer does, and it’s getting tiresome.
Of course a good developer can avoid these problems for the most part. The point is that we want the bad developers to be forced to do things a safe way by default.
Even good developers make mistakes. It’s really nice to catch these mistakes at compile time.
Is there a way to jailbreak an Android phone using this exploit?
You could just unlock the bootloader
Assuming the bootloader is unlockable
Rolling release stays winning
This is the best summary I could come up with:
It’s the result of a use-after-free error, a class of vulnerability that occurs in software written in the C and C++ languages when a process continues to access a memory location after it has been freed or deallocated.
At the time this Ars post went live, there were no known details about the active exploitation.
A deep-dive write-up of the vulnerability reveals that these exploits provide “a very powerful double-free primitive when the correct code paths are hit.” Double-free vulnerabilities are a subclass of use-after-free errors that occur when the free() function for freeing memory is called more than once for the same location.
The write-up lists multiple ways to exploit the vulnerability, along with code for doing so.
The double-free error is the result of a failure to achieve input sanitization in netfilter verdicts when nf_tables and unprivileged user namespaces are enabled.
Some of the most effective exploitation techniques allow for arbitrary code execution in the kernel and can be fashioned to drop a universal root shell.
The original article contains 351 words, the summary contains 168 words. Saved 52%. I’m a bot and I’m open source!
Is this even new?
I thought this already circulated a few months back.
Even Debian stable has already patched it.
The are actually some of the fastest
RHEL on the other hand
