From BeepingComputer.

  • qaz@lemmy.world
    link
    fedilink
    arrow-up
    127
    ·
    edit-2
    1 year ago

    A new Linux vulnerability known as ‘Looney Tunables’ enables local attackers to gain root privileges by exploiting a buffer overflow weakness in the GNU C Library’s ld.so dynamic loader.

    It’s always memory management

      • GreyBeard@lemmy.one
        link
        fedilink
        arrow-up
        63
        arrow-down
        1
        ·
        1 year ago

        It’s certainly why it is being used to build browsers and OSs now. Those are places were memory management problems are a huge problem. It probably doesn’t make sense for every match 3 game to be made in Rust, but when errors cause massive breaches or death, it’s a lot safer than C++, taking human faulability into account.

        • AggressivelyPassive@feddit.de
          link
          fedilink
          arrow-up
          22
          arrow-down
          1
          ·
          1 year ago

          Question would be rather: why is something like C++ needed for such simple apps?

          C++ seems to be in that weird in-between place of offering high level features to be reasonable productive, but still doesn’t enforce/guarantee anything to make these features safe. I’d argue, very few programs need that. Either you’re writing business stuff, then you want safety (Java, C#, rust), or you’re writing embedded/low level stuff, then you want control (C, ASM).

          The room for “productive, but not interested in safety” is basically just AAA games, I guess.

          • intelati@programming.dev
            link
            fedilink
            arrow-up
            11
            arrow-down
            1
            ·
            1 year ago

            C is almost the old “steady” standard now it feels like. It’s so flexible and the frameworks are already built…

            • entropicdrift@lemmy.sdf.org
              link
              fedilink
              arrow-up
              15
              ·
              1 year ago

              …except that we also end up with cracks in our foundations like this exploit constantly being exposed as a result of all that C

          • teawrecks@sopuli.xyz
            link
            fedilink
            arrow-up
            7
            ·
            1 year ago

            Well you’re not going to write asm if you want your code to be portable at all, and believe it or not C++ has a lot of features to help you not shoot yourself in the foot that C doesn’t have (ex. OOP, RAII, smart pointers).

            C wasn’t really designed with dynamic memory management in mind. It was designed for someone who has absolute control over a machine and all the memory in it. malloc() and free() are just functions that some environments expose to user mode processes, but C was never designed to care where you got your memory or what you do with it.

          • ziviz@lemmy.sdf.org
            link
            fedilink
            English
            arrow-up
            7
            ·
            1 year ago

            The short answer is Rust was built with safety in mind. The longer answer is C was built mostly to abstract from assembly without much thought to safety. In C, if you want to use an array, you must manually request a chunk of memory, check to make sure you are writing within the bounds of your array, and free up the memory used by your array when completely done using it. If you do not do those steps correctly, you could write to a null pointer, cause a buffer overflow error, a use-after-free error, or memory leak depending on what step was forgotten or done out of order. In Rust, the compiler keeps track of when variables are used through a borrowing system. With this borrowing system the Rust compiler requests and frees memory safely. It also checks array bounds at run-time without a programmer explicitly needing to code it in. Several high-level languages have alot of these safety features too. C# for example, can make sure objects are not freed until they fall out of scope, but it does this at run-time with a garbage collector where Rust borrower rules are done at compile-time.

            • Affine Connection@lemmy.world
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              1 year ago

              C was built mostly to abstract from assembly

              That’s actually not true; rather, many modern architectures are designed to allow languages like C to be compiled more easily. Old architectures don’t even have a built-in stack.

          • Michael Murphy (S76)@lemmy.world
            link
            fedilink
            English
            arrow-up
            5
            ·
            edit-2
            1 year ago

            The compiler enforces “aliasing XOR mutability”; utilizes “move semantics”; has a “borrowing and ownership” model; and requires the programmer to tag their references with “lifetimes”. Array accesses are checked at runtime if they cannot be guaranteed safe at compile-time. Variables passed by value (moved) cannot be reused. Variables cannot be moved or mutated if any borrow to them exists. You may either have only one mutable borrow, or many immutable borrows, but never both. Therefore you cannot mutate an array while iterating on it, and you cannot have two separate unchecked references to the same array. Every function or type that accepts a borrow must be able to annotate the lifetimes of references to ensure that references are always dropped in the correct order to prevent dangling references. Rust requires developing software with discipline using patterns that satisfy all of these constraints.

    • Eezyville@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      36
      arrow-down
      1
      ·
      1 year ago

      Didn’t Microsoft do a study on security vulnerabilities and found that the overwhelmingly number of bugs was due to memory management?

  • NateNate60@lemmy.ml
    link
    fedilink
    arrow-up
    55
    arrow-down
    1
    ·
    1 year ago

    It says “sysadmins should prioritise patching”, but… has it been patched yet?

  • Veticia@lemmy.ml
    link
    fedilink
    arrow-up
    36
    arrow-down
    1
    ·
    1 year ago

    I wonder if this could be used to root previously unrootable Android based devices.

    • palordrolap@kbin.social
      link
      fedilink
      arrow-up
      7
      ·
      edit-2
      1 year ago

      Makes me wonder. LMDE got a glibc update too and Mint is very much not leading edge when it comes to non-critical updates.

      Case in point, at roughly the same time as the glibc update, we (LMDE users) were upgraded to the latest Thunderbird, 115.3.1, four or five days after that sub-version came out. That’s the sort of lag we generally see. (115.x was a bit of a surprise too as we’ve been on 102.x, but that’s not strictly relevant here.)

      • Unkend@lemmy.world
        link
        fedilink
        arrow-up
        7
        arrow-down
        1
        ·
        edit-2
        1 year ago

        LMDE is 100% using Debian packages for the core OS if you want a newer Thunderbird go to flathub.

        edit.

        • palordrolap@kbin.social
          link
          fedilink
          arrow-up
          5
          ·
          1 year ago

          I only mentioned the lag to make the point that if we’re getting an update at the same time as Arch that maybe it was an important one.

          Anyone on Mint who finds themselves trying to leap ahead of the default release schedule might want to at least sniff around a different distro or two.

          That said, Flatpaks with later versions are also often available in the provided Software Manager (basically an app store), so that’s a place to look before jumping ship. Hard to tell now, but I think 115 was the Flatpak option while the, uh, default default was 102.