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.
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.
Lol. You have no idea what you are talking about about here 😂
Clearly you have no idea. Rust makes this kind of bug impossible.
It is still possible to have security vulnerabilities in Rust
‘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.
Nobody claimed otherwise.
Utopia or nothing!
That’s not what’s at issue her LOL
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
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…
Neither do I. What’s Rust in this context?
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.
Rust is a programming language. Not to be confused with the video game.
Is that videogame written in that programming language?
Nope. Rust is a low level language.
c/woooosh
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
Yes, that’s right. You cannot have a UAF situation unless you’re using unsafe “escape hatch” tools.
Again… IMPROBABLE
C++ would also solve this for the same reason!!
If this is a joke, I don’t get it
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.
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.
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.
If you follow modern C++ best practices, memory unsafety will not happen by accident. The dodgy stuff in modern, idiomatic C++ is immediately obvious.
Yes but the whole point is that Rust forces you to do this.
Not everybody follows best practices, sometimes people who say they do, well they make mistakes.
I really don’t understand how this is conceptually difficult to grasp.
Rust forces you to do this until you have to use unsafe, after which it doesn’t. That is not so different from C++ guaranteeing your safety until you start using raw pointers.
It is not the compiler’s job to stop the programmer from shooting themselves in the foot if they want to. It’s the compiler’s job to make it clear to the programmer when they disable the safety, put their finger on the trigger and aim the gun at their foot. Modern C++ does this, and if you still inadvertedly shoot yourself in the foot in spite of the warnings, you brought it on yourself.
Regular old C, on the other hand, gives you a 9mm when you’re in grade 7, safety: always off.
Rust still has memory related bugs
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.
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)
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.
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.