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.

top 92 comments

sorted by: hot top controversial new old
[–] 90 points 1 year ago (12 children)

This only affects positively ancient kernels:

From (including) 3.15 Up to (excluding) 5.15.149 From (including) 6.1 Up to (excluding) 6.1.76 From (including) 6.2 Up to (excluding) 6.6.15 From (including) 6.7 Up to (excluding) 6.7.3

  • source
  • hideshow 12 child comments
  • [–] 16 points 1 year ago (5 children)

    If I’m not mistaken, RHEL9 and equivalents are on 5.15. That’s a pretty big blast radius.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 4 points 1 year ago (2 children)

    Debian Bookworm (Debian 12/oldstable) would be affected then, I think?

  • source
  • parent
  • hideshow 2 child comments
  • [–] 29 points 1 year ago (3 children)

    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.

  • source
  • hideshow 3 child comments
  • [–] 13 points 1 year ago (2 children)

    Except for supply chain attacks. You get a foot in the door, and open the rest with impunity

  • source
  • parent
  • hideshow 2 child comments
  • [–] 31 points 1 year ago (9 children)

    Local attacker? So on your LAN

  • source
  • hideshow 9 child comments
  • [–] 25 points 1 year ago (7 children)

    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.

  • source
  • parent
  • hideshow 7 child comments
  • [–] 9 points 1 year ago (6 children)

    So a non issue unless somebody has physical access to the machine?

  • source
  • parent
  • hideshow 6 child comments
  • [–] 8 points 1 year ago (3 children)

    No. They just have to be able to place exploit code onto your machine and have it run.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 0 points 1 year ago (2 children)

    If they can place exploit code on my machine, I think its already game over, regardless of that bug

  • source
  • parent
  • hideshow 2 child comments
  • [–] 8 points 1 year ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • 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.

  • source
  • [–] 16 points 1 year ago (6 children)

    Feeling pret-ty smug about my Windows 10 machine rn ngl

  • source
  • hideshow 6 child comments
  • [–] 8 points 1 year ago (4 children)

    Lol because Windows has never been exploited

  • source
  • parent
  • hideshow 4 child comments
  • [–] 1 point 1 year ago (3 children)
  • [–] 5 points 1 year ago*

    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.)

  • source
  • parent
  • [–] 20 points 1 year ago (57 children)

    And that kids, is why we are pushing for Rust in the Kernel

  • source
  • hideshow 57 child comments
  • [–] 2 points 1 year ago* (3 children)

    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)

  • source
  • parent
  • hideshow 3 child comments
  • [–] 20 points 1 year ago (2 children)

    Old fuckers exist to protect young fuckers from throwing out the baby with the bath water.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 1 year ago

    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.

  • source
  • parent
  • [+] -13 points 1 year ago (37 children)

    Lol. You have no idea what you are talking about about here 😂

  • source
  • parent
  • hideshow 37 child comments
  • [–] 22 points 1 year ago* (19 children)

    Granted, I was mostly shit posting. But in all seriousness: wouldn't Rust prevent that kind of exploit by inherent design?

    Due to Rust’s ownership semantics, when we free a value, we relinquish ownership on it, which means subsequent attempts to use the value are no longer valid.

    https://stanford-cs242.github.io/f18/lectures/05-1-rust-memory-safety.html

  • source
  • parent
  • hideshow 19 child comments
  • [–] 8 points 1 year ago (2 children)

    Yes, that's right. You cannot have a UAF situation unless you're using unsafe "escape hatch" tools.

  • source
  • parent
  • hideshow 2 child comments
  • [–] -3 points 1 year ago (1 child)
  • [–] 3 points 1 year ago

    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.

  • source
  • parent
  • [–] 4 points 1 year ago (10 children)

    C++ would also solve this for the same reason!!

  • source
  • parent
  • hideshow 10 child comments
  • [–] 6 points 1 year ago (9 children)

    If this is a joke, I don't get it

  • source
  • parent
  • hideshow 9 child comments
  • [–] 1 point 1 year ago

    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.

  • source
  • parent
  • [–] 1 point 1 year ago (7 children)

    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::move a 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.

  • source
  • parent
  • hideshow 7 child comments
  • [–] 5 points 1 year ago (6 children)

    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.

  • source
  • parent
  • hideshow 6 child comments
  • [–] -1 points 1 year ago (5 children)

    If you follow modern C++ best practices, memory unsafety will not happen by accident. The dodgy stuff in modern, idiomatic C++ is immediately obvious.

  • source
  • parent
  • hideshow 5 child comments
  • [–] 3 points 1 year ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] -2 points 1 year ago*

    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.

  • source
  • parent
  • [–] 2 points 1 year ago (2 children)

    I would love to see a study about people that follow C++ best practices. Put a bunch of C++ devs and tell them to write some programs. Then see how many of those programs would be valid according to rust's borrow checker.

    Whatever % of people that "fail" this test, is much higher than the 0% of people that would do so using rusts' compiler.

    Of course, programs that don't pass the borrow checker can be totally memory safe, but that would need to be analyzed on a case by case basis.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 1 point 1 year ago (1 child)

    Whatever % of people that "fail" this test, is much higher than the 0% of people that would do so using rusts' compiler.

    Of course, programs that don't pass the borrow checker can be totally memory safe, but that would need to be analyzed on a case by case basis.

    Programs that do pass the borrow checker aren't guaranteed to be totally memory safe, so the number isn't actually 0% for Rust either: https://github.com/Speykious/cve-rs

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 1 year ago

    Yes, I know about that one. That is code made specifically to reproduce a bug in the compiler. Unless you do it on purpose, there's no way you'd get hit by it. If it were, they would have fixed it, it's been known for several years.

  • source
  • parent
  • [–] 1 point 1 year ago (2 children)

    Rust still has memory related bugs

  • source
  • parent
  • hideshow 2 child comments
  • [–] 7 points 1 year ago (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 2 points 1 year ago

    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)

  • source
  • parent
  • [–] -5 points 1 year ago* (1 child)

    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.

  • source
  • parent
  • hideshow 1 child comment
  • [–] 10 points 1 year ago*

    Everything has bugs that surface.

    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.

    See my other link, or look yourself.

    The link you posted says nothing about Rust software having bugs, it's about malware written in Rust exploiting bugs in other software.

  • source
  • parent
  • [+] 11 points 1 year ago (10 children)
  • [–] -4 points 1 year ago (4 children)

    It is still possible to have security vulnerabilities in Rust

  • source
  • parent
  • hideshow 4 child comments
  • [–] 3 points 1 year ago

    '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.

  • source
  • parent
  • [+] -9 points 1 year ago* (4 children)

    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

  • source
  • parent
  • hideshow 4 child comments
  • [+] 5 points 1 year ago (2 children)
  • [–] -2 points 1 year ago (1 child)

    🤦 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.

  • source
  • parent
  • hideshow 1 child comment
  • load more comments (1 reply)
  • [–] 1 point 1 year ago (5 children)

    Neither do I. What's Rust in this context?

  • source
  • parent
  • hideshow 5 child comments
  • [–] 5 points 1 year ago

    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.

  • source
  • parent
  • [–] 2 points 1 year ago (3 children)

    Rust is a programming language. Not to be confused with the video game.

  • source
  • parent
  • hideshow 3 child comments
  • [+] -12 points 1 year ago (5 children)

    Rust would not of fixed this

    Rust isn't magical

  • source
  • parent
  • hideshow 5 child comments
  • [–] 30 points 1 year ago (2 children)

    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.

  • source
  • parent
  • hideshow 2 child comments
  • [–] -1 points 1 year ago (5 children)

    Okay, then why we need to use a language that has more in common with OCaml? What about using a better C instead?

  • source
  • parent
  • hideshow 5 child comments