Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Bug Security Linux

Linux Glibc Security Fix Created a Nastier Linux Bug (zdnet.com) 74

Posted by BeauHD from the unintended-consequences dept.
A fix that was made in early June to the GNU C Library (glibc) introduced a new and nastier problem. Steven J. Vaughan-Nichols writes via ZDNet: The first problem wasn't that bad. As Siddhesh Poyarekar, a Red Hat principal software engineer wrote, "In order to mount a minimal attack using this flaw, an attacker needs many pre-requisites to be able to even crash a program using this mq_notify bug." Still, it needed patching and so it was fixed. Alas, the fix contained an even nastier bug. While checking the patch, Nikita Popov, a member of the CloudLinux TuxCare Team, found the problem. It turns out that it is possible to cause a situation where a segmentation fault could be triggered within the library. This can lead to any application using the library crashing. This, of course, would cause a Denial-of-Service (DoS) issue. This problem, unlike the earlier one, would be much easier to trigger. Whoops.

Red Hat gives the problem in its Common Vulnerability Scoring System (CVSS) a score of 7.5, which is "high." An attack using it would be easy to build and requires no privileges to be made. In short, it's bad news. Popov himself thinks "every Linux application including interpreters of other languages (python, PHP) is linked with glibc. It's the second important thing after the kernel itself, so the impact is quite high." [...] The good news is both the vulnerability and code fix have been submitted to the glibc development team. It has already been incorporated into upstream glibc.

In addition, a new test has been submitted to glibc's automated test suite to pick up this situation and prevent it from happening in the future. The bottom line is sometimes changed in unrelated code paths can lead to behaviors changing elsewhere without the programmer realizing what's going on. This test will catch this situation. The Linux distributors are still working out the best way to deploy the fix. In the meantime, if you want to be extra careful -- and I think you should be -- you should upgrade to the newest stable version of glibc 2.34 or higher.
This discussion has been archived. No new comments can be posted.

Linux Glibc Security Fix Created a Nastier Linux Bug More

Linux Glibc Security Fix Created a Nastier Linux Bug

Comments Filter:

  • It happens... (Score:2, Interesting)

    by sg_oneill ( 159032 )

    As ugly as it is. This is a workplace hazard of being a coder. Even with the best test suites, sometimes a bugs introduced that triggers in somewhere unexpected and sirens go off, and lots of unhappiness, but even god-like coders can make this happen.

    Lets hope this doesnt affect too many producion deployments.

    • Re:It happens... (Score:5, Insightful)

      by Nkwe ( 604125 ) on Monday August 16, 2021 @09:01PM (#61699285)
      It does happen. However when it happens at Microsoft, the response here is a lot different...

      • Re: (Score:1, Troll)

        by 93 Escort Wagon ( 326346 )

        I disagree. I think the responses are pretty much the same, it’s just that the people involved switch sides.

        • I dunno, there's an intersection of people that dislike both Microsoft and IBM (Red Hat) :)

          Some would argue for alternatives to glibc such as musl or Theo's heavily audited openbsd. Rustaceans would argue it's folly to implement a C library in an unsafe language like C and suggest relibc.

          But anyway, concurrency is hard.

          • Re: (Score:1)

            by Chrisq ( 894406 )

            Some would argue for alternatives to glibc such as musl or Theo's heavily audited openbsd. Rustaceans would argue it's folly to implement a C library in an unsafe language like C and suggest relibc.

            Still others would argue that we should never have abandoned the scroll and quill pen, that we would be a lot happier calculating by hand.

            Apologies, something in OP's style made me think of Douglas Adams

            • But then again an electric pen would make sense to some since we already have electric guitars, can openers,....electric cars...?

          • I would settle for people not complaining that languages other than C are unnecessary because it is possible to write secure code on the first try every time if you just get good.

      • Two sides of the same coin.

        For the *nix geek it feels like an orgasm with every keystroke using *nix. But when he uses Windows, he feels like he's getting fucked by every mouse click.

        Go figure what kind of dissonance that can spawn.

      • Redhat basically has the skillset of IBM now, which is a little scary.

      • Re: (Score:1)

        by gweihir ( 88907 )

        When it happens to Microsoft, it is typically found much later and usually only if somebody actively attacks it. The joy of closed-source software. Also, Microsoft does rarely learn from mistakes. They are making the same stupid mistakes over and over and over again.

        Bit of a different situation there.

        • Re: (Score:2)

          by Malc ( 1751 )

          This is probably because all their experienced people have left and have been replaced by cheaper junior people who think they should reinvent the wheel.

          I tried to use the ATL wizard in VS 2017 recently, only to find it completely and utterly broken. For some reason, it looked like somebody had tried to reimplement it without understanding even the basics and clearly hadn't used it or had any kind of regression tests. VS6 worked better.

      • Re: (Score:2)

        by rastos1 ( 601318 )

        It does happen. However when it happens at Microsoft, the response from Microsoft is a lot different...

        FTFY

    • I'm wondering why... (Score:5, Interesting)

      by Larsen E Whipsnade ( 4686581 ) on Monday August 16, 2021 @09:36PM (#61699367)
      something as old and as fundamental as glibc hasn't had all the bugs shaken out of it many years ago.

      Have they been churning the code with unwanted new features and dubious performance enhancements?

      • You're right, libc is a pretty hard target after all these years. To the extent that even a brand new DoS discovered by white hats instantly becomes front page tech news. Because these are few and far between. What's more, they don't last long and an army of skilled admins will be out there patching vulnerable machines.

        Can't really make such boasts about Windows. In that world you just sit around and wait for reboot Tuesday. Collect your paycheck. Life of a Windows admin.

      • Because there is essentially no such thing as bug free code.
        The expectation - through code maturity - is that the number approaches zero, but that doesn't mean it ever gets there.

      • Have they been churning the code with unwanted new features and dubious performance enhancements?

        Unwanted by whom? Dubious according to whom? One man's bloat is another's critical feature.

        When you're not talking out of your arse you may be interested to know that a lot of changes in glibc have been to implement newer and better security practices, provide support for new CPU extensions such as SSE4.1/4.2, and supporting new architectures like RISC-V.

        You may be happy with your Pentium MMX from the 90s, the rest of us are not.

        • It's a fundamental library, not a race car. There is such a thing as fast enough, but no such thing as too stable. And therefore no call for any special case code for new architectures. Priorities, people.

          You want speed optimization? Spin yourself a custom library and leave the rest of us out of it. As for newer and better security practices, I would be all for that, except... it doesn't seem to have worked out that way in this case.

          I'm of the opinion that without built in bounds checking, a language can ne

          • Re: (Score:3)

            by tlhIngan ( 30335 )

            It's a fundamental library, not a race car. There is such a thing as fast enough, but no such thing as too stable. And therefore no call for any special case code for new architectures. Priorities, people.

            You want speed optimization? Spin yourself a custom library and leave the rest of us out of it. As for newer and better security practices, I would be all for that, except... it doesn't seem to have worked out that way in this case.

            I'm of the opinion that without built in bounds checking, a language can ne

          • It's a fundamental library, not a race car.

            Which is precisely why it's so damn important to optimise it. Do you put diesel in your Ferrari?

          • Actually your post deserves a longer reply. You seem to be under the impression that a fundamental library is somehow meant to be slow or that optimisation is somehow at odds with stability both API and actual stability.

            I'm not sure where you got that idea from but I think the technical definition for it is "horseshit". Speed optimisation has been of the upmost and fundamental importance at the most core level of every OS and library in general use. I personally think you have it completely backwards.

            If you

            • cases such as the one this topic is about.

              It's called the real world.

              • Yes, the real world where in the past 30 years we have demonstrated the single most important part of IT has been to steadily increase its speed to cope with demand.

                Your real world argument directly works against you, whether you're a kid playing games bench-marking OSes, a cloud provider attempting to edge out performance per watt (dollar) in your database or filesystems, or a financial behemoth trying to make that trade just a little bit faster.

                The entire world runs on speed. Only a few edge cases case ab

                • I see security incidents all the time. I don't see speed issues, unless you count DDoS.

                  Speed kills. We all know that.

                  • I see security incidents all the time. I don't see speed issues, unless you count DDoS.

                    Speed kills. We all know that.

                    No. You've normalised speed issues and thus are desensitised to them. There's a difference. On a slightly related note, the world is being fucked up ecologically, please don't waste power and produce more CO2 by running shitty inefficient code.

      • Have they been churning the code with unwanted new features and dubious performance enhancements?

        The primary issue is that GlibC does not conform to any standard. No, seriously, it doesn't use standard code (utilizes GCC compiler extensions), it's not POSIX compliant and has a boatload of "features" added to it.

        If you want a reliable and compliant libc then you should look at musl [libc.org] which actually focuses on being small, POSIX compliant, and ensuring security.

    • Hate to say it, but this is a very basic demonstration of why we need to start using Rust throughout the kernel. We have tools that provide memory safety, and we've proven that humans can't get memory safety perfect in general, even in the most high stakes scenarios

    • Re: (Score:2)

      by Bengie ( 1121981 )
      I haven't seen glibc in the news almost ever. Seeing how widely it's used speaks for its relative quality. But so many people use "people make mistakes" as an excuse for shit design and code all the time. I recently inherited a project that was "done". Just needed final QA and deployment. This project was code reviewed and tested. I read through the code and found swaths of defects. I've have yet to run it and I've changed out hundreds of lines.

      This is not a one time deal. This happens all the time. The r

  • Nothing is perfect (Score:3, Insightful)

    by memory_register ( 6248354 ) on Monday August 16, 2021 @09:20PM (#61699327)
    That is why we have major releases, minor releases, patches, updates, hot fixes!

  • Hyperbole, it's what's for dinner (Score:2, Informative)

    by Anonymous Coward

    Okay so there is a bug in the implementation of a glibc function, mq_notify(). As far as I know, mq_notify isn't really used by that many applications. So there is some small intersection of programs that both a) use mq_notify() and b) will have a major impact on the world if they no longer were running.

    More importantly, this article doesn't even mention what software might have issues with this bug, or how it impacts anything.

    Flapping your head saying that EVERYTHING uses glibc isn't helpful. Sure, eve

    • Re:Hyperbole, it's what's for dinner (Score:4, Interesting)

      by Tough Love ( 215404 ) on Monday August 16, 2021 @10:40PM (#61699551)

      Right, calling it a "libc bug" is misleading, it's a Posix message queue bug. An application using Posix message queues might be vulnerable, which s is a tiny subset of applications because Posix message queues are rather obscure, but there are so many millions of Linux servers that absolute numbers could be large. Whether this is anything more than a potential DoS or whether it can be exploited remotely remains to be analyzed.

      Doesn't look particularly threatening, the main news here that fixing a hole made a new hole, however small.

      • Right, calling it a "libc bug" is misleading

        No, it's not, because the bug is in the implementation of mq_notify in librt.

        it's a Posix message queue bug. An application using Posix message queues might be vulnerable

        Yes, which is part of libc.
        If there's a bug in printf, do you also claim that it's not a bug in libc, because it only affects things that use printf?

        Sure, mq_notify isn't used by a lot of shit, but the bug is absolutely in libc (librt).

        mqueue is useful as IPC in lots of places. It's simpler than writing your own semaphore back message queue, works across multiple processes, doesn't need all the annoyance of dbus, and is less w

    • Re: (Score:2)

      by djgl ( 6202552 )

      I agree, a quick check with
      find /bin/ /sbin/ /lib /lib64 -type f | xargs nm -D | grep mq_notify | wc -l
      (/xyz symlinked to /usr/xyz) found zero applications on my computer.

      • Re: (Score:2)

        by kimhanse ( 60133 )

        I have found one application on my system using the Posix message queues, stress-ng (https://kernel.ubuntu.com/~cking/stress-ng/)

        Doesn't seem like a very critical bug.

        • A meta-application to stress test conformity of a feature is its sole usage!

          Thus a bunch of obsolete code exists in the Linux kernel only so it can claim to be POSIX compatible with something they thought was useful decades ago.

    • I do not see why that would be considered a critical bug. No privilege escalation and no remote DOS. Basically, someone found a new way for programmers to crash their own code. It must be fixed of course but this is a rather mundane issue. It seems to me that Tuxcare, the company that found the second bug, is trying to make the buzz.

      • Because it allows someone to crash any code whatsoever that may be listening on a certain mqueue.
        That is absolutely a critical bug.

  • Do not forget to patch... everything! (Score:5, Insightful)

    by ptaff ( 165113 ) on Monday August 16, 2021 @10:26PM (#61699515) Homepage

    In the good old days it would've meant a one-shot update to glibc per system, and maybe sometimes for the odd chroot-jailed application.

    Nowadays, it means updating all containers too (docker, LXC, snap, flatpak), so unless they're all homemade, a hunt for online updates, hoping upstream isn't slow to react.

    Just like in this other operating system we laugh at when it comes to security.

    Aren't we getting somewhere nice?

    • Perhaps first check if any of the software that you run on your systems even use posix message queues, should be possible to be fully scriptable.

    • Re: (Score:2)

      by gweihir ( 88907 )

      One reason why containers are stupid. I expect they do not really have a long-term future, they are just a current hype that overpromises and underdelivers.

      • Containers would be cool as hell if they weren't their own fucking application environment. They're not quite linux. They're pretty close.
        And just to keep things fun, that environment is developed in a RAD like way, so you couldn't keep ahead of it if you fucking wanted.

        They have taken a cool functionality (that actually existed long before Docker et al, made it popular- I added container support to my HTC G1 a lifetime ago) in linux and turned into a steaming fucking pile of shit.

        • Re: (Score:2)

          by gweihir ( 88907 )

          I think they fill a small niche only: They are not application packages (which, with chroot + privilege drop can be isolated pretty well and can be given their own libraries if needed or desired), and they are not quite VMs. They still have the drawbacks of VMs, namely that you need to do system maintenance and, in part at least, system administration for them. They also have the drawbacks of packages, namely they are dependent in some ways on the machine they get installed on.

          Quote a bad mix, actually, whe

          • Yes, when I was first playing with containers (well, linux kernel namespacing, which today's "containers" are just user-space management of that feature) I was just using it for more advanced sandboxing than you can get simply by chrooting.
            I remember thinking the technology was fucking awesome. This was back in 2009 or so, though... and I never thought they'd turn into these weird fucking living packages with their own little pseudo OS going on inside them... and the model of having some janky ass containe

        • Containers seem to be a symptom of dependency hell.

    • Ya, the big corporate distributions have finally managed to put the worst fucking parts of Windows and macOS into linux.
      Yay, us.

  • Just fix the uninitialized memory Ala Debian ssl....

    No one will notice the keyspace has drastically been reduced.... you fixed a valgrind warning so all is well.

Slashdot Top Deals

Your own mileage may vary.

Close