Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
Check out the new SourceForge HTML5 internet speed test! No Flash necessary and runs on all devices. ×
Bug GNU is Not Unix Google Open Source Red Hat Software Security

Red Hat, Google Disclose Severe Glibc DNS Vulnerability; Patched But Widespread 121

An anonymous reader writes: Today Google's online security team publicly disclosed a severe vulnerability in the Gnu C Library's DNS client. Due to the ubiquity of Glibc, this affects an astounding number of machines and software running on the internet, and raises questions about whether Glibc ought to still be the preferred C library when alternatives like musl are gaining maturity. As one example of the range of software affected, nearly every Bitcoin implementation is affected. Reader msm1267 adds some information about the vulnerability, discovered independently by security researchers at Red Hat as well as at Google, which has since been patched: The flaw, CVE-2015-7547, is a stack-based buffer overflow in the glibc DNS client-side resolver that puts Linux machines at risk for remote code execution. The flaw is triggered when the getaddrinfo() library function is used, Google said today in its advisory. "A back of the envelope analysis shows that it should be possible to write correctly formed DNS responses with attacker controlled payloads that will penetrate a DNS cache hierarchy and therefore allow attackers to exploit machines behind such caches," Red Hat said in an advisory. It's likely that all Linux servers and web frameworks such as Rails, PHP and Python are affected, as well as Android apps running glibc.
This discussion has been archived. No new comments can be posted.

Red Hat, Google Disclose Severe Glibc DNS Vulnerability; Patched But Widespread

Comments Filter:
  • by dentar ( 6540 ) on Tuesday February 16, 2016 @01:54PM (#51520653) Homepage Journal

    ... because the proposed replacement will be bug-free, right?

    • Re: (Score:3, Insightful)

      by eumoria ( 2741315 )
      Yes! There's always a software solution that's secure and bug free 100% of time they just didn't pick the right one. The fools!
    • by SumDog ( 466607 )

      I was thinking this was another push to get off of GPLv3 code (like clang vs gcc), but it looks like glibc is LGPL.

    • There's a story from ancient Rome about a wealthy man who wanted to find the best singer in his city. So he put out a call for all of the women in the city to come to his mansion to compete in a singing contest. Two women chose to compete. At the appointed time the man asked the first woman to do her piece - it was pretty bad. He immediately awarded the prize to the second woman.

      This story is often used to illustrate how people will jump to "there ought to be a law" non-solutions while ignoring the better m

  • Eh? (Score:1, Interesting)

    by Anonymous Coward

    "discovered independently by security researchers at Red Hat as well as at Google" - How does that happen, and when DID it happen?

    • by raymorris ( 2726007 ) on Tuesday February 16, 2016 @03:47PM (#51521755) Journal

      How does it happen that two people independently notice a bug? They both run the program, and it crashes because there's a bug. They're both running the same code, so they get the same crash. It's not immediately obvious that the crash has any security impact, and if so, how severe.

      In the case of Red Hat and Google, both have teams who fix bugs in Linux, so whoever notices it files a bug report for the appropriate team. At Red Hat, when it's noticed that there are potential security implications, it's sent to Florian's team. Florian's team works carefully to fully understand it, look for related issues*, and work out the BEST way to fix it. They have a pile of bugs they're working at any given time.

      Over at Google, the bug was found later, but the severity of the security implications were noticed sooner, so Google found the security issue WHILE Red Hat was working through their process.

      * An example of Red Hat's "find and fix the whole issue, not just the obvious part", is shell shock. After the initial CVE for shell shock, several people proposed different ways of fixing it. Florian was one, he quickly worked on it and released a proposed patch. Over the next few days there were three MORE CVEs for shell shock, covering different variations on the same theme. Florian's initial patch covered all of them, including the ones that hadn't been fully characterized when he proposed it. His approach was approved by general consensus and that's what we all use today - partly because he put in the time and effort to fix the broader issue, not just the specific case that had been identified. This approach means that sometimes it takes Red Hat a while to release a fix, but when they do, it's the right fix.

    • by ssam ( 2723487 )
      Maybe some static analysis tool recently gained a feature that finds it. Maybe some conference talk mentioned some new method that helped find it. Maybe they were both aware of someone using this exploit.
  • Seriously, that was the best example you could come up with from "an astounding number of machines and software"?

    Isn't there something - anything - affected that more people actually care about or are impacted by?

    • Re: (Score:2, Funny)

      What about the linux based pacemaker that controls my heart? I'm sure it is saaaeffeeaeafeitgaPOl
    • I'm curious on what this means. Does every application that was compiled with this flaw need to be recompiled? Just ones that rely on DNS, or none?

      • "The flaw is triggered when the getaddrinfo() library function is used"

        That function is used a lot.
        • by cfalcon ( 779563 )

          But it has to result in a DNS inquiry (so if your addresses are stored locally, you're ok), and it has to go to a malicious DNS server or somehow be served a malicious DNS packet in response.

          • But it has to result in a DNS inquiry (so if your addresses are stored locally, you're ok)

            So you're saying we should use a hosts file?

            • by cfalcon ( 779563 )

              A lot of applications demand a hosts file already, because a DNS can be compromised more easily than an IP can be spoofed. Obviously this isn't a general solution for a generic server or useful desktop.

      • Re:Bitcoin? (Score:5, Informative)

        by Anonymous Coward on Tuesday February 16, 2016 @02:37PM (#51521063)

        If you are statically linked AND you do something that results in DNS resolution (like resolving a hostname to IP), then yea, you'd need a recompile. If you are dynamically linked than probably you will pull down a fixed library. Alternatively, they do have a patch. Also they have a workaround you can use if that's impractical, where you limit the DNS size response.

        In the wild this will be nontrivial to exploit because you already choose your DNS servers with some care, and DNS servers are already a target (and therefore reasonably hardened) because of all the phat lewtz you can harvest if you point people to your fake address). So it's a serious vulnerability but not one that could instantly go wormy on us.

        • by Etcetera ( 14711 )

          If you are statically linked AND you do something that results in DNS resolution (like resolving a hostname to IP), then yea, you'd need a recompile.

          And this is why static linking and non-use-of-system-libraries is bad, unless done for very specific reasons and with a very specific update policy.

        • This sounds very very difficult to exploit if for no other reason than needing to control a DNS server and reply with malformed packets that won't trigger an intrusion detection system like Snort (there is probably already a rule built).

        • by Bengie ( 1121981 )

          In the wild this will be nontrivial to exploit because you already choose your DNS servers with some care

          You don't need to choose your servers with care, you can just host your own, and register a domain. Few hundred dollars for the kind of domain you need? Register sefdarrhdrah4w3563eya54.com and get someone to resolve abc.sefdarrhdrah4w3563eya54.com and watch them hit your server. As long as the caching server between you and the target allows large/oversized DNS responses, which goes back to how common are DNS servers hardened.

    • I think it's just timothy trying to inject some eye-catching words in the headline for click-baiting.

  • by Anonymous Coward

    Because I know it cheats, lies, steals, and snitches. I am prepared. On guard. Never taken by surprise. But this, this is just unacceptable, and outrageous.

  • Can someone get a list of versions that are fixed instead of bitching about that there are bugs? There are always another bug, regardless of system. If you want it bug free, then start to write new tests that tests things not yet tested.

    Looks like glibc-2.22-9.fc23 and glibc-2.21-11.fc22 contains the fix.
    What about other releases?

  • by Anonymous Coward

    All things considered I'm doing quite well for myself.

    First I was saved from heart bleed heartache by using oldest still maintained branch of OpenSSL at the time.

    Now I have dodged getaddrinfo apocalypse by using an old as hell version of glibc.

    Personally I tend to discount c library bugs as all the ones I knew about were never practically applicable or triggerable. Not much different from processor errata. This would be the first exception I've been made aware of in quite a number of years.

    • by Z00L00K ( 682162 )

      You may have escaped bugs that made the news but instead you have other bugs that are less prominent.

      Whatever you do you are cursed.

  • Ha! I knew procrastination would pay off! Debian Lenny has libc 2.7, and so is not vulnerable.

    *gloat*

  • by Anonymous Coward

    https://ipleak.net/

    When is Google going to fix the bug in webrtc which gives out the users internal and real IP addresses?

    If you use a VPN and Chrome click the link above to test to see if your IP address is being broadcast.

C for yourself.

Working...