• @[email protected]
    link
    fedilink
    English
    1485 months ago

    For your convenience:

    The researchers pointed out that the vulnerability cannot be exploited remotely. An attacker can trigger the issue by providing crafted inputs to applications that employ these [syslog] logging functions [in apps that allow the user to feed crafted data to those functions].

    This is a privilege escalation.

    • @db2
      link
      525 months ago

      The hero we need."; DROP TABLE “users”;

    • @[email protected]
      link
      fedilink
      44 months ago

      This may be difficult to exploit in practice - I don’t think most user applications use syslog.

        • @[email protected]
          link
          fedilink
          94 months ago

          You still need some privileged process to exploit. Glibc code doesn’t get any higher privileges than the rest of the process. From kernel’s point of view, it’s just a part of the program like any other code.

          So if triggering the bug in your own process was enough for privilege escalation, it would also be a critical security vulnerability in the kernel - it can’t allow you to execute a magic sequence of instructions in your process and become a root, that completely destroys any semblance of process / user isolation.

  • @shadowintheday2
    link
    English
    965 months ago

    "A qsort vulnerability is due to a missing bounds check and can lead to memory corruption. It has been present in all versions of glibc since 1992. "

    This one amazes me. Imagine how many vulnerabilities future researchers will discover in ancient software that persisted/persist for decades.

    • @[email protected]
      link
      fedilink
      65
      edit-2
      5 months ago

      That’s not the main part of the article, just a footnote, for anyone wondering.

      The flaw resides in the glibc’s syslog function, an attacker can exploit the flaw to gain root access through a privilege escalation.

      The vulnerability was introduced in glibc 2.37 in August 2022.

        • @StefanT
          link
          214 months ago

          glibc is a library, gcc is the compiler.

        • @[email protected]
          link
          fedilink
          54 months ago

          You are probably confusing the glibc with gcc and g++. Glibc is an implementation of the C standard library, made by GNU (thats where the g in the name comes from).

          If you were to look into it, it uses the syscalls to tell the underlying computer system what to do when you call functions, such as printf.

          If you want to read more, see here

    • @[email protected]
      link
      fedilink
      334 months ago

      C is just crazy. You accidentally forget to put the bounds in a sorting function, and now you are root.

    • @[email protected]
      link
      fedilink
      65 months ago

      According to the link in the article, the qsort() bug can only be triggered with a non-transitive cmp() function. Would such a cmp function ever be useful?

      • @Giooschi
        link
        English
        44 months ago

        You don’t necessarily have to write a non-transitive cmp() function willingly, it may happen that you write one without realizing due to some edge cases where it’s not transitive.

  • Atemu
    link
    fedilink
    455 months ago

    Security-critical C and memory safety bugs. Name a more iconic duo…

    I’d have kinda preferred for public disclosure to have happened after the fix propagated to distros. Now we get to hurry the patch to end-users which isn’t always easily possible. Could we at least have a coordinated disclosure time each month? That’d be great.

      • Atemu
        link
        fedilink
        114 months ago

        They did follow that. You can read their disclosure timeline in their report.

        Problem is that the devs of glibc aren’t the only people interested in getting glibc patched but us distro maintainers too.

        What I would have preferred would be an early private disclosure to the upstream maintainers and then a public but intentionally unspecific disclosure with just the severity to give us distro people some time to prepare a swift rollout when the full disclosure happens and the patch becomes public.

        Alternatively, what would be even better would have been to actually ship the patch in a release but not disclose its severity (or even try to hide it by making it seem like a refactor or non-security relevant bugfix) until a week or two later; ensuring that any half-decent distro release process and user upgrade cycle will have the patch before its severity is disclosed. That’s how the Linux kernel does it AFAIK and it’s the most reasonable approach I’ve seen.

  • @[email protected]
    link
    fedilink
    294 months ago

    glibc is great, but holy shit the source code is obscured into oblivion, so hard to understand, with hardcoded optimizations, and compiler optimizations. I understand how difficult is to find vulnerabilities. A bit sad that the only C lib truely free software is so hard to actually read its code or even contribute to it.

    • @[email protected]
      link
      fedilink
      English
      21
      edit-2
      4 months ago

      For what it’s worth, glibc is very much performance-critical, so this shouldn’t be a surprise. Any possible optimization is worth it.

      There are a ton of free software libc implementations outside of glibc. I think most implementations of libc are free software at this point. There’s Bionic, the BSD libcs, musl, the Haiku libc, the OpenSolaris/OpenIndiana libc, Newlib, relibc, the ToaruOS libc, the SerenityOS libc and a bunch more. Pretty sure Wine/ReactOS also have free implementations of the Windows libc.

      • @[email protected]
        link
        fedilink
        24 months ago

        Glibc has extensions that fragment compatibility. If Glibc is replaced by another libc, some apps prints an error, or don’t work. I noticed that on Alpine.

    • @[email protected]
      link
      fedilink
      English
      5
      edit-2
      4 months ago

      Eventually it’ll be easier to create a compatible drop-in replacement than maintain the decades old code, if it isn’t already

      • @FooBarrington
        link
        114 months ago

        Unlikely, unless you drop backwards compatibility for undefined behaviour. Unless you write a complete specification on it, you’ll end up either breaking old stuff, or slowly rebuilding the same problems.

        • @[email protected]
          link
          fedilink
          34 months ago

          Wayland is not a drop-in replacement tho. It’s like if glibc developers declared it obsolete and presented a “replacement” that has a completely different API and has 1/100 of glibc functionality and a plugin interface. And then all the dozens of Linux distros have to write all the plugins from scratch to add back missing functionality and do it together in perfect cooperation so that they remain compatible with each other.

  • @[email protected]
    link
    fedilink
    275 months ago

    Debian (versions 12 and 13), Ubuntu (23.04 and 23.10), and Fedora (37 to 39). Other distributions are probably also impacted.

        • Rustmilian
          link
          English
          4
          edit-2
          4 months ago

          While there may be challenges and specific configurations required, you absolutely can compile Rust on and targeting to a musl-based system.

            • Rustmilian
              link
              English
              4
              edit-2
              4 months ago

              Rust actually supports most architectures(SPARC, AMD64/x86-64, ARM, PowerPC, RISC-V, and AMDGPU*). The limitations are from LLVM not supporting some architects(Alpha, SuperH, and VAX) and some instruction sets(sse2, etc.); z/Architecture is a bit of an outlier that has major challenges to overcome for LLVM-Rust. This is not going to be a problem when GCC-Rust is finished.

              AMDGPU, *Not 100%, but works well enough to actually use in production and gets better all the time.

                • Rustmilian
                  link
                  English
                  4
                  edit-2
                  4 months ago

                  Np. It’s a common point of confusion.
                  You can use rustup target list to see all available architectures and targets.

        • @[email protected]
          link
          fedilink
          English
          7
          edit-2
          4 months ago

          At a time where proprietary software is becoming more and more nasty and prevalent, on top of what has always accompanied it, we shouldn’t be letting proprietary software developers take advantage of free code only to lock theirs away as proprietary. It advantages nobody except proprietary devs, who don’t have the users at heart.

          The goal of the GPL is to fight that.

          The problem with pushover licenses like MIT in this case is that a lot of this software is designed to displace copylefted code. And when it does, you lose the protection of copyleft in that particular area and all of a sudden proprietary software gets a leg up on us. It’s bad for software freedom and the users by extension, and good for proprietary software developers.

          • But the licence is chosen by the software author - unless that right to choose is taken away by a viral licence like the GPL, of course. In any case, I licence everything I write that I can as 3-clause BSD because I don’t give a fuck. I wrote the software for me, and it costs me nothing if it’s used by a shitty proprietary software stealer, or a noble OSS developer. Neither of them are paying me.

            OSS should, is, and eventually will drive for-pay software to extinction, and it should do it through merit, not some legal trickery.

            • @[email protected]
              link
              fedilink
              English
              3
              edit-2
              4 months ago

              You’re missing the point. Yes, the license is chosen by the author, but if that pushover licensed software becomes favoured over copyleft software, then proprietary software has a leg up as I explained. That’s it.

              GPL is also not a “viral” license, because that would imply that it seeks out and infects anything it can find. But developers choose which code they use, it doesn’t just appear in their own code without permission. So a better analogy would be “spiderplant” license, since you’re taking part of a GPL program (a spiderplant), and putting it in your own (where the GPLs influence “grows” to). That is completely the software developers decision and not like a virus at all.

              It might not cost you anything personally if a proprietary developer usurps your code, but it does cost overall user freedom and increases proprietary dominance, where copyleft licenses would have done the opposite if your code was worth using. For that reason, I like strong copyleft. But by all means, keep using the license you want to, as long as it’s not proprietary I won’t judge. This is just my thoughts.

              The point of free/open source licenses isn’t to remove money from software either, it’s perfectly possible to sell libre software. It’s about what the recipients of that software have the freedom to do with it, and not giving the developer control over their users. We should serve the community, not betray them.

              Lastly, although free alternatives are often technically superior to their closed-source competitors, at the end of the day, if you have a slightly faster program which does nasty spying, locking of functionality, etc, and a slightly slower program which does not, I’d be inclined to say that the slower program should be preferred by virtue that it does not do nasty things to it’s users, and that then you won’t be supporting such behaviour.

              • Lastly, although free alternatives are often technically superior to their closed-source competitors, at the end of the day

                I am 100% in agreement with you here. While I’m not by any means a Libertarian, I prefer MIT and BSD licenses because they are truely free. The GPL is not: it removes freedoms. Now, you argue that limiting freedom can be a net good - we limit the freedom to rape and murder, and that’s good. I don’t agree that the freedoms the GPL removes are equivalent, and can indeed be harmful.

                I don’t mind others using the GPL, but I won’t.

                • @[email protected]
                  link
                  fedilink
                  English
                  34 months ago

                  We can agree to disagree on the freedom point. The only “freedom” I see being taken away with the GPL is the removing of the freedom of other people.

                  I don’t mind the MIT/BSD licenses, but I won’t use them. We can agree on that.

        • @[email protected]
          link
          fedilink
          34 months ago

          I get is more liberal which I understand why. But that means that changes to the software do not need to be shared. Which for normal users it really does not matter. But again we are giving to multi corporations so much in exchange of nothing. When again they don’t treat their users the same way.

          MIT is a good licence as an idea. In reality, multi corporations are evil AF. The idea of free software in a sense is that free software can get so much better than privative one, eventually forcing privative companies to implement it them self on their programs.

          If giving and taking was 1:1 in software community then again, MIT license is perfect. In reality it isn’t. For major programs that have a lot of implication on new programs I do not recommend MIT and similar. For feature like projects is totally okay IMO.

          • I respect your opinion on this, and will say only one more thing: having worked in the corporate software space for decades, you don’t want their software. Most of it is utter crap. It’s a consequence of finance having too much indirect influence, high turnover, a lot of really uninspired and mediocre developers, and a lack of the fundamentally evolutionary pressures that exist in OSS. The only thing corporations do better is marketting.

    • @[email protected]
      link
      fedilink
      -85 months ago

      The vulnerability is on logs, and that has nothing related to the library. Even less with the language…

      • @Quetzalcutlass
        link
        English
        16
        edit-2
        5 months ago

        The vulnerability is in the library’s logging function, which is coded in the C language. musl is also C (afaik), it’s just a more modern, safer rewrite of libc.

        I’m not sure what you mean by a “vulnerability in the logs”. In a logger or parser, sure, but did you think text data at rest was able to reach out and attack your system?

        • @[email protected]
          link
          fedilink
          -14 months ago

          True, the logging is part of the library, but it’s totally centered on what the developers are logging. It’s a bad practice to log sensitive information, which can be used by someone with access to the logs for sure, but that doesn’t mean the library is broken and has to be replaced. The library’s logs need to be audited, and this as true for glibc as it is for musl, no exception, and it’s not a one time thing, since as the libraries evolve, sensitive information can be introduced unintentionally (perhaps debugging something required it on some particular testing, and it was forgotten there).

          BTW, what I meant with the language, is that no matter the language, you might unintentionally allow some sensitive information in the logs, because that’s not a syntactic error, and it’s not violating any compiling rules. It’s that something is logged that shouldn’t.

          Also, the report indicates that the vulnerability can’t be exploited remotely, which reduces the risk for several systems…

          • @[email protected]
            link
            fedilink
            5
            edit-2
            4 months ago

            The vulnerability has nothing to do with accidentally logging sensitive information, but crafting a special payload to be logged which gets glibc to write memory it isn’t supposed to write into because it didn’t allocate memory properly. glibc goes too far outside of the scope of its allocation and writes into other memory regions, which an attacked could carefully hand craft to look how they want.

            Other languages wouldn’t have this issue because

            1. they wouldn’t willy nilly allocate a pointer directly like this, but rather make a safer abstraction type on top (like a C++ vector), and

            2. they’d have bounds checking when the compiler can’t prove you can go outside of valid memory regions. (Manually calling .at() in C++, or even better - using a language like rust which makes bounds checks default and unchecked access be opt in with a special method).

            Edit: C’s bad security is well known - it’s the primary motivator for introducing rust into the kernel. Google / Microsoft both report 70% of their security vulnerabilities come from C specific issues, curl maintainer talks about how they use different sanitizers and best practices and still run into the same issues, and even ubiquitous and security critical libraries and tools like sudo + polkit suffer from them regularly.

            • @[email protected]
              link
              fedilink
              44 months ago

              I see, I didn’t dig into the cause, being sort of a buffer overflow. Indeed that would be prevented by other languages, sorry for my misinterpretation. Other vulnerabilities unintentionally introduced by developers on logging what shouldn’t are not dependent on anything other than auditing them, but that was not the case then.

  • @[email protected]
    link
    fedilink
    164 months ago

    Yikes.

    I’d switch to musl on all of my boxes if it weren’t that nearly all precompiled software (closed source, games mainly) are compiled against glibc.

    • @Falcon
      link
      44 months ago

      Just use flatpak and podman, in a punch you can proot into a different system / zfs data set / btrfs sublime

      • @[email protected]
        link
        fedilink
        64 months ago

        Void offers musl too. Unless they’ve discontinued it.

        But

        compile everything yourself?

        I do (almost) exactly that. I run Gentoo almost everywhere. The ‘almost’ is because Gentoo now offers an official bin repository too, so I can mix compiled and pre-compiled software. (Although you’ve always had the option to set up your own binary host).

        • Rustmilian
          link
          English
          44 months ago

          How are you going to run steam though? Like at least alpine has wine, but there’s no way to recompile steam unfortunately.

  • UnfortunateShort
    link
    164 months ago

    That’s why you need to rock and roll

    (Arch btw.)

    • @ouch
      link
      64 months ago

      Try having unattended-upgrades with a rolling distro.

        • @shadowintheday2
          link
          English
          94 months ago

          Just don’t upgrade for a while and you become debian

          It’s not like windows forcing you to reboot every Tuesday so Edge can come back

      • Man, I do this all the time. snapper and grub-btrfs has enabled all kinds of amazing things. I’m so close to just doing:

        $ sudo crontab -l
        * * 3 * * pacman -Syu --no-confirm
        

        I’ve got separate offline backups and rescue disks, but I’m pretty confident that grub-btrfs will let me recover pretty quickly.

        • bruhduh
          link
          3
          edit-2
          4 months ago

          grub-btrfs with timeshift didn’t helped me in my upgrade from fedora 38 to 39, when i rolled back with grub-btrfs, what loaded was weird mix of 38 and 39, that didn’t even let me browse my filesystem, got to disassemble laptop, get out ssd, use it as external, and even then half of the ssd was locked, ssd was new and chmod didn’t helped, even from live usb, had to copy files with testdisk and dd zero’s on whole disk for it to work again

    • @Unyieldingly
      link
      34 months ago

      Ubuntu 22.04 LTS, Linux Mint etc as well. also this is a local one, so not many people care.

    • @[email protected]
      link
      fedilink
      English
      44 months ago

      I’d just like to interject for a moment. What you call “GNU Library C” is actually GNU with Linux library C and some C++ for those nifty templates, or as we like to call it “GNU/Linux Library C/C++”. Which, to be honest, it’s more like “GNU/Linux Library C/C-with-Classes” the way they’re teaching it at school, oh well.

      Carry on.

      • @[email protected]
        link
        fedilink
        14 months ago

        I was, it seems, too subtle. I don’t call it “GNU Library C”. Nobody does. I call it the “GNU C library”. It’s weird that the author calls it that.

        • @[email protected]
          link
          fedilink
          English
          24 months ago

          Aaaaaand I somehow missed that.

          Then again, wouldn’t have changed much. I’d just infodumped you on the GNU/Linux C Library, or as we sometimes call it the GNU plus Linux C library with macros.

          • @[email protected]
            link
            fedilink
            24 months ago

            Aaaaaand I somehow missed that.

            Not the only one it seems - that’s on me.

            GNU plus Linux C library with macros.

            🤣

    • Rustmilian
      link
      English
      34 months ago

      GNU C Library(glibc) as apposed to C Library (libc).