Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by timothy on from the patched-upstream-that-is dept.

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.

121 comments

  1. Yet another call for replacement... by dentar · · Score: 5, Insightful

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

    --
    -- I am. Therefore, I think!
    1. Re:Yet another call for replacement... by Anonymous Coward · · Score: 0

      Musl is rather mature. Works and doesn't suck.

    2. Re:Yet another call for replacement... by eumoria · · Score: 3, Insightful

      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!

    3. Re:Yet another call for replacement... by Anonymous Coward · · Score: 0

      Especially when they haven't reached maturity yet. I don't think software ages like humans do. Older software doesn't naturally gain more bugs nor forget features.

      I guess if software libraries have constant churn hackers won't have time to learn and target all of the versions, though neither will the developers be able to use them effectively. Security by obscurity instead of by well written code is now the recommended form!

    4. Re:Yet another call for replacement... by SumDog · · Score: 1

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

    5. Re: Yet another call for replacement... by bill_mcgonigle · · Score: 2

      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 methods, but really it speaks to the nature of any human who has not been trained in rational thought.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    6. Re:Yet another call for replacement... by Anonymous Coward · · Score: 0

      Well, nothing is bug free, but you won't have to deal with that steaming pile of dung that is glibc

      Drepper was Pottering before Pottering was uncool.

    7. Re: Yet another call for replacement... by Anonymous Coward · · Score: 5, Funny

      He immediately awarded the prize to the second woman.

      Systemd?

    8. Re:Yet another call for replacement... by Anonymous Coward · · Score: 0

      Well, I use Microsoft Windows and...

    9. Re: Yet another call for replacement... by Anonymous Coward · · Score: 0

      And statically links wonderfully. Great for portable tools.

    10. Re:Yet another call for replacement... by Anonymous Coward · · Score: 0

      considering what some elite people want to have, maybe this is not a coincidence ?

    11. Re: Yet another call for replacement... by Anonymous Coward · · Score: 0

      450 lbs and she won't move out

    12. Re: Yet another call for replacement... by Anonymous Coward · · Score: 0

      So when a bug is found in its implementation, you need all those portable tools individually recompiled instead of just fixing the underlying library. Great.

  2. Time to Fork by Anonymous Coward · · Score: 0

    LibreGlibC to teh rescue!

  3. This replacement is better because...? by Anonymous Coward · · Score: 0

    What the hell makes us think musl won't have vulnerabilities?

    1. Re:This replacement is better because...? by DickBreath · · Score: 1

      The same thing that makes me think that anything written in C would never have this type of vulnerability.

      --

      I'll see your senator, and I'll raise you two judges.
  4. If only... by Anonymous Coward · · Score: 0

    Oh look, yet another memory safety violation. If only a systems programming languages had been developed that eradicated this entire class of software bug.

    1. Re:If only... by Z00L00K · · Score: 2

      BLISS - used to program OpenVMS.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    2. Re:If only... by Anonymous Coward · · Score: 0

      Stop trying to make Rust happen. It's not going to happen.

    3. Re:If only... by rubycodez · · Score: 1

      haha you are funny. BLISS had no I/O, that was all external calls. Guess where more vulnerabilities come into play?

    4. Re:If only... by gweihir · · Score: 1

      That is not possible, despite some big fat liars claiming their pet tool can do it. Either systems programming or memory safety. You cannot get both.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    5. Re:If only... by Anonymous Coward · · Score: 0

      if you say that Hillary, I am sure C will continue to be mainstream.

    6. Re:If only... by Anonymous Coward · · Score: 0

      Ignorance is BLISS. :-)

    7. Re:If only... by Eunuchswear · · Score: 1

      haha you are funny. BLISS had no I/O, that was all external calls. Guess where more vulnerabilities come into play?

      All I/O is done with external calls in C too.

      Of course Z00L00K is full of shit, BLISS is just as bad as C:

      Z+12=14

      is BLISS for

      *(&Z +12) = 14

      Bye bye memory safety.

      --
      Watch this Heartland Institute video
    8. Re:If only... by rubycodez · · Score: 1

      you misunderstand, C has standard functions for I/O, BLISS does not

  5. Eh? by Anonymous Coward · · Score: 1, Interesting

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

    1. Re:Eh? by Anonymous Coward · · Score: 0

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

      Many many people discover the same bug because many many people are looking for exploits to use against others and don't disclose the bugs so they hopefully won't be fixed soon, making the exploits useful life time longer.

      I happen to know as fact this exploit has been for rent on the russian site lions den for close to five years now.

      I would also place bets the exploit has been known of for even longer than that.

    2. Re:Eh? by ssam · · Score: 1

      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.

  6. Here's an idea by Anonymous Coward · · Score: 0

    Fold it into systemd, so we have a more modern OS. There is nothing wrong with glibc except the jerk who maintains it.

    1. Re:Here's an idea by Anonymous Coward · · Score: 2, Insightful

      systemd's own resolver is still dealing with decade old bugs like spoofed responses and poisoning attacks.

    2. Re:Here's an idea by F.Ultra · · Score: 1

      While the initial version of systemd-resolvd didn't honor rfc5452 due to it beeing a stub resolver, it has since v223: https://lists.freedesktop.org/...

      * systemd-resolved now implements RFC5452 to improve resilience against
      cache poisoning. Additionally, source port randomization is enabled
      by default to further protect against DNS spoofing attacks.

    3. Re: Here's an idea by Anonymous Coward · · Score: 0

      Version 223? Are you kidding me? What kind of numbering scheme is this? I suspect good ol Len Pot made it this way so it looks more mature than it really is. In reality it's a piece of shit code base that solves nothing but faster boot times. To do basic shit that was already available by default in other systems now makes you edit files and add weird flags to get the same functionality.

      Version 223, give me a fucking break. This shit should still be in beta.

  7. Bitcoin? by 93+Escort+Wagon · · Score: 1

    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?

    --
    #DeleteChrome
    1. Re:Bitcoin? by 110010001000 · · Score: 1, Funny

      What about the linux based pacemaker that controls my heart? I'm sure it is saaaeffeeaeafeitgaPOl

    2. Re:Bitcoin? by JackieBrown · · Score: 1

      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?

    3. Re:Bitcoin? by 110010001000 · · Score: 2

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

      That function is used a lot.

    4. Re:Bitcoin? by Anonymous Coward · · Score: 0, Funny

      Dude, this is serious. Just yesterday I found that my Coinye West server was missing 53 million dollars. I had to ask Mark Zuckerberg and Larry Page to front me some more Coinye.

    5. Re:Bitcoin? by Megaweapon · · Score: 1

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

      --
      I'm sure "SlashdotMedia" will improve on all the wonders that Dice Holdings blessed us all with
    6. Re:Bitcoin? by Anonymous Coward · · Score: 5, Informative

      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.

    7. Re:Bitcoin? by cfalcon · · Score: 2

      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.

    8. Re:Bitcoin? by Anonymous Coward · · Score: 0

      Bitcoin's actually a good example of the way this call gets abused into atypical uses. The Bitcoin client's initial peer discovery happens rather promiscuously using DNS seeds.

    9. Re:Bitcoin? by Etcetera · · Score: 1

      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.

      --
      Hire a Linux system administrator, systems engineer,
    10. Re:Bitcoin? by Anonymous Coward · · Score: 0

      if your pacemaker configuration is correct it should failover to another node in the cluster without issue

    11. Re:Bitcoin? by Anonymous Coward · · Score: 0

      Yeah, I'm sure you'd be so much better off it ran Windows. Just like the woman a few years back in Sweden, who nearly died a few years ago, when the hospitals IT staff decided to run an anti-virus scan (I swear to God I'm not shitting you) on her dialysis machine.

    12. Re:Bitcoin? by rahvin112 · · Score: 1

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

    13. Re:Bitcoin? by Anonymous Coward · · Score: 0

      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
      The authors beg to differ of this requiring malformed packets directly talking to the target. They seem to think DNS caches could be exploited:

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

    14. Re:Bitcoin? by Anonymous Coward · · Score: 0

      The only thing on my system that I specifically make sure is statically linked is my rescue shell and a copy of busybox. While there are other things that may be made that way by the distro, many don't do the rescue shell, which seems completely wrong to me. If your system goes crap up, you can do a surprisingly large amount of work with the shell and its built-ins and busybox is a nice backup when all else fails.

      While on the subject of recovery, I try to stay away from Live CDs. Many of those not only bring up the network interface by default, but also OPEN and LISTEN on ports. Yeah, lets put an out-of-date SSH server on public interfaces, there is a good idea.

    15. Re:Bitcoin? by Anonymous Coward · · Score: 0

      This world is rotten security-wise and I know one medical industry software engineer (he studied with me) and he is 100% rotten in terms of security, too.

      You better go to hospital under a fake name or they can assassinate you via the network. That inter-network which reaches Pyongyang and FtMeade.

      Having written that, the worst problem is probably this inter-network being connected to Cheltenham....

    16. Re:Bitcoin? by Anonymous Coward · · Score: 0

      Maybe you really believe you're not shitting us, but Google knows nothing about this alleged incident

    17. Re:Bitcoin? by Bengie · · Score: 1

      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.

    18. Re:Bitcoin? by Eunuchswear · · Score: 1

      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?

      --
      Watch this Heartland Institute video
    19. Re:Bitcoin? by cfalcon · · Score: 1

      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.

    20. Re: Bitcoin? by Anonymous Coward · · Score: 0

      That is why you have a firewall in place. The live CD can boot up a web server, that's fine, because as long as you aren't on my network, you won't see it.

    21. Re:Bitcoin? by Anonymous Coward · · Score: 0

      So if I'm using, say, Google own DNS servers (8.8.8.8), I'm basically OK-ish?

  8. OpenBSD is the best replacement for Linux. by Anonymous Coward · · Score: 0, Interesting

    OpenBSD is the best replacement for Linux and GNU software, especially if you care about security. The OpenBSD developers can't write bug-free code, but when we consider the extreme care and effort they put into ensuring their code is of an extraordinarily high quality then we realize that their work is as close to bug-free as we are realistically going to get. It does make sense to switch to the best available alternative. The OpenBSD devs do everything just about as correctly as can be done. They put security first. They carefully review their own code and that of others. They will even fork code developed by others if it doesn't meet the OpenBSD standards! They don't implement bad ideas, like systemd, to begin with. They say it as it is, even if it may hurt somebody's feelings. They don't put up with bullshit, especially if it could put security at risk. They are the role models that everybody else in open source software development should follow and strive to be like.

    1. Re:OpenBSD is the best replacement for Linux. by Anonymous Coward · · Score: 2, Insightful

      Uhhhhh, maybe a Linux user like you wouldn't understand this, but minimizing the attack surface is one of the first things to do when securing anything. Yes, OpenBSD has a limited base system. That's the best thing you could ask for! That way you can install OpenBSD and know exactly what you're working with. There are no surprises. Then you layer on the additional functionality that you need. It's a small amount of effort, but the security payoff is massive. Linux distros often do it totally backward, where they install a bunch of shit by default that then needs to be removed. That's just plain dumb!

    2. Re:OpenBSD is the best replacement for Linux. by rubycodez · · Score: 1

      base system has openssh server, web server, , some scripting languages, mail, routing and firewall.

      for more than that there are binary packages that include all the usual for servers and desktops, and ports for even more.

    3. Re:OpenBSD is the best replacement for Linux. by rubycodez · · Score: 1

      much as I love OpenBSD I'm betting ALL the open source BSD have this problem too. a project's goals can be lofty but the security and bug find/fixing reality applies to them too

    4. Re:OpenBSD is the best replacement for Linux. by Luthair · · Score: 1

      Given that the problem was in a low level library, if a similar problem occurred in the OpenBSD equivalent having a limited number of packages installed would probably still leave the system vulnerable. (Though it would probably still have fewer ways to attack it.)

    5. Re:OpenBSD is the best replacement for Linux. by Anonymous Coward · · Score: 1

      Not that I'm exactly a fan of Mr The Rat and his not so merry gang of asshats, but "still vulnerable" isn't the same as "equally vulnerable". The more services/applications you have installed and are running, possibly without even knowing it, the more likely someone or something will find a gap, even it's the same one.

    6. Re:OpenBSD is the best replacement for Linux. by Anonymous Coward · · Score: 1

      You'd lose that bet. OpenBSD doesn't use glibc; it uses its own BSD-based libc. Android doesn't use glibc either, its libc is a mashup of linux and BSD libc's (mostly OpenBSD accd to the Google developers). AFAIK all BSD's - whether they use gcc or clang - use a BSD-based libc. Don't know if that includes Apple OS X; it's more BSD-flavored than BSD-derived.

    7. Re:OpenBSD is the best replacement for Linux. by Anonymous Coward · · Score: 0

      who is paying you for your evil words ?

      or is it just the common devil worshipping of your culture?

    8. Re:OpenBSD is the best replacement for Linux. by doconnor · · Score: 1

      You can get a limited base system and control what is being installed by using Gentoo Linux, while gaining the benefits of all the things that support Linux.

    9. Re:OpenBSD is the best replacement for Linux. by rubycodez · · Score: 1

      that's good; I did look at the ports, yup they don't have separate glibc for them thank goodness

      mac osx doesn't have but now I have to check out these porting systems...

    10. Re:OpenBSD is the best replacement for Linux. by F.Ultra · · Score: 1

      The problem with that thinking is that if you plan to do the same job with a OpenBSD machine vs SomethingElse then both will probably run the exact number and type of services and applications.

    11. Re:OpenBSD is the best replacement for Linux. by EmeraldBot · · Score: 1

      Uhhhhh, maybe a Linux user like you wouldn't understand this, but minimizing the attack surface is one of the first things to do when securing anything. Yes, OpenBSD has a limited base system. That's the best thing you could ask for! That way you can install OpenBSD and know exactly what you're working with. There are no surprises. Then you layer on the additional functionality that you need. It's a small amount of effort, but the security payoff is massive. Linux distros often do it totally backward, where they install a bunch of shit by default that then needs to be removed. That's just plain dumb!

      The problem OpenBSD has for security is the versions they use. Go ahead, search around online, and you'll see the version of Firefox their still using: version 39, I believe. The problem with being lax about new packages is that they're still using a vulnerable version of Firefox, which I don't think their built in features can protect, and that's a much bigger security risk than some handy W^X. And even W^X's usefulness is disputed, actually...

      --
      "Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
    12. Re:OpenBSD is the best replacement for Linux. by EmeraldBot · · Score: 1

      who is paying you for your evil words ?

      or is it just the common devil worshipping of your culture?

      No, that's the other BSD :-)

      And when it comes to our operating systems of choice, it's not a religion. Far more faith than one.

      --
      "Set a man a fire, he'll be warm for the rest of the night. Set a man afire, he'll be warm for the rest of his life."
    13. Re: OpenBSD is the best replacement for Linux. by Anonymous Coward · · Score: 0

      You do know that you have the option to port it from the -current branch, right? This will give you the latest and greatest, if you so choose.

  9. "LibreGlibc" already exists! by Anonymous Coward · · Score: 0

    "LibreGlibc" already exists, and has existed for ages!

    You can find the source code here:
    http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/
    http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libm/

    There are numerous other superb libraries, too:
    http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/

  10. Re:Maybe a solution by Anonymous Coward · · Score: 0

    Maybe Google and Redhat should stop just leeching of off Open Source and actually fund it all. They are literally making billions in cash off of Open Source infrastructure components every month and their contributions back are less than 1% of their profits.

    Glibc? Gee, I wonder who was responsible for allowing/putting the vulnerability in the code?

  11. And this is why I insist on Windows 10 by Anonymous Coward · · Score: 2, Funny

    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.

    1. Re:And this is why I insist on Windows 10 by Anonymous Coward · · Score: 0

      Lie, cheat, and steal? What a TOOL.

  12. Instead of bitching, get a list of fixed versions. by Z00L00K · · Score: 1

    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?

    --
    If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  13. Why does a C library need a DNS client? by Anonymous Coward · · Score: 0

    Doesn't the operating system already have one? The more different implementations are running on your system, the more different potential ways to fuck up there are.
    Besides that, from a software design perspective, isn't DNS and networking code in general a bit outside the scope of a language runtime library?

    1. Re:Why does a C library need a DNS client? by kthreadd · · Score: 5, Informative

      Doesn't the operating system already have one?

      Yeah it has one, the one in the C library.

    2. Re:Why does a C library need a DNS client? by Anonymous Coward · · Score: 0

      That's so fucked up, I don't even know what to say.

    3. Re: Why does a C library need a DNS client? by Anonymous Coward · · Score: 0

      Remember that the "C library" stems from the days when there were just C. All other languages uses it too nowadays, so it is really just one shared implementation. The alternative would be to put it in the kernel, and you really don't want to put things like this in kernel space.

  14. Re:Maybe a solution by Anonymous Coward · · Score: 1

    They do fund quite a bit of it. In this particular case the glibc maintainer works for Red Hat.

  15. Saved by rust again by Anonymous Coward · · Score: 1

    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.

    1. Re:Saved by rust again by Z00L00K · · Score: 1

      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.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
  16. What? by Anonymous Coward · · Score: 0

    >and raises questions about whether Glibc ought to still be the preferred C library when alternatives like musl are gaining maturity

    What? Let's stop using a well-tested and mature platform because we found one big vulnerability for it, and instead use immature alternatives? Has everyone's brain fallen out completely or something?

    1. Re:What? by Luthair · · Score: 1

      What? Let's stop using a well-tested and mature platform because we found one big vulnerability for it, and instead use immature alternatives? Has everyone's brain fallen out completely or something?

      Its a common problem in software development, we all look at existing code and think its a mess and there could be a simpler solution. Which is true if you forget all the edge cases and bugs that were fixed making it convoluted.

  17. CentOS by Anonymous Coward · · Score: 0

    I don't see any updated packages for CentOS 6 yet. Crazy...

    1. Re:CentOS by kthreadd · · Score: 1

      CentOS has to wait until Red Hat releases their source RPMs, then they have to rebuild them, test them and distribute to all their mirrors.

      Pay for a RHEL subscriptions if you want your patches fast.

    2. Re:CentOS by Anonymous Coward · · Score: 0

      CentOS never patches quickly. You're on the wrong distro for that. Arch/Debian are usually very fast to patch.

    3. Re:CentOS by Anonymous Coward · · Score: 0

      Pay for a RHEL subscriptions if you want your patches fast.

      Bam! The motive behind RedHat's "magnanimous" propping-up of the CentOS house of cards is finally revealed.

    4. Re:CentOS by Anonymous Coward · · Score: 0

      Actually it has always been this way. Red Hat produces the patch. Uploads the source to its FTP site. The leeches come in, recompile, release their own patches for the cloned Red Hat variants.

    5. Re:CentOS by Anonymous Coward · · Score: 0

      Well, it's not really leeching. Red Hat has done a lot of great work on GNU/Linux but they have absolutely not done all. So Red Hat is just as much "leeching" on the GNU/Linux community when they "take" their source code and package it for RHEL.

    6. Re:CentOS by ShaunC · · Score: 1

      Check again, they showed up sometime last night.

      glibc.x86_64 2.12-1.166.el6_7.7
      glibc-common.x86_64 2.12-1.166.el6_7.7
      glibc-devel.x86_64 2.12-1.166.el6_7.7
      glibc-headers.x86_64 2.12-1.166.el6_7.7

      --
      Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
  18. same bug crashes same way on both machines by raymorris · · Score: 4, Informative

    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.

    1. Re:same bug crashes same way on both machines by Anonymous Coward · · Score: 0

      Over the next few days there were three MORE CVEs for shell shock, covering different variations on the same theme.

      No, the sudden interest in bash caused people to find more bugs, completely unrelated to the first one.

      Florian's initial patch covered all of them, including the ones that hadn't been fully characterized when he proposed it.

      I guess you mean the patch that only imports functions from environment variables beginning with BASH_FUNC_, rather than any environment variables as before. This is a precautionary measure which makes it harder for attackers to exploit bugs in the parser, which is a good thing but doesn't fix the bugs themselves.

      His approach was approved by general consensus and that's what we all use today

      We use this approach in addition to the fixes for the individual bugs.

  19. Re:Anti-GPL bullshit by Anonymous Coward · · Score: 1

    People calling for switching from glibc to musl are anti-GPL political opportunists. The Linux equivalent of gun control freaks who immediately call for stricter laws whenever there is a shooting.

    And if you look at all the countries in the world, with and without strict gun control, and especially the countries that have introduced stricter gun controls than before, the facts in terms of killings (intentional and unintentional) overwhelmingly seem to support strict gun control being a very good idea. So what you are saying is that musl is a good idea?

  20. Vindicated again! by Areyoukiddingme · · Score: 1

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

    *gloat*

    1. Re: Vindicated again! by Anonymous Coward · · Score: 0

      Well, it just has all the other exploits.

    2. Re:Vindicated again! by Anonymous Coward · · Score: 0

      Shellshock fixing forced many Lenny installs up to 2.13

      check your version via

      ldd --version

    3. Re:Vindicated again! by Anonymous Coward · · Score: 0

      via apt-cache on my box

      eglibc is 2.13-32
      provides glibc-2.13-1

      libc6 is 2.7-18lenny7
      provides glibc-2.7-1

      so probably screwed...

  21. VERY WRONG by Anonymous Coward · · Score: 0

    ELBRUS, ICL and Unisys proved you wrong. That was BEFORE the C shite came into existence.

    But hey, why do we need Italian cuisine after the invention of the hamburger. Everybody knows "new is better"....

    1. Re:VERY WRONG by gweihir · · Score: 1

      They did not have memory-mapped I/O, unlike basically any hardware available today. But hey, why accept facts when you can throw something completely irrelevant into the mix.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    2. Re:VERY WRONG by tibit · · Score: 1

      Memory-mapped I/O as a programming primitive is not the same as memory-mapped I/O as a binary interface between the code and the hardware. You can safely abstract the binary interface out without making the entire programming language unsafe...

      --
      A successful API design takes a mixture of software design and pedagogy.
    3. Re:VERY WRONG by gweihir · · Score: 1

      Only if you language knows about all present and future hardware and its exact functionality. Incidentally, even if you could do that (which you cannot), the result would not be a "systems programming language" anymore.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    4. Re:VERY WRONG by tibit · · Score: 1

      Not really. You want the unsafe bits to be compartmentalized in a binary interface specification - that's the unsafe part of the language. That specification isn't a part of the programming language, but a part of your software! You provide it to the tools so that the tools know what kind of an interface to generate. Historically, C/C++ conflates the binary interface with higher-level abstractions. E.g. a C struct is forced to imply a certain implementation-defined memory layout, and that's quite stupid. The high-level "record" abstraction shouldn't force the compiler to choose anything in particular as far as memory layout goes. If a particular layout is desired, a separate binary-interface should be specified, and its use compartmentalizes the unsafe aspect of your software's specification that way. That's just an example, of course.

      --
      A successful API design takes a mixture of software design and pedagogy.
    5. Re:VERY WRONG by gweihir · · Score: 1

      Well, I do understand what you are saying (I think) and it has been done before. Problem is, if you have access to main memory only through abstractions (or drivers), then that kills performance for a great many things. The very purpose of a systems programming language is to not have that performance loss. Also, interface definitions are just as subject to error as interface implementations, that path does not work. The "interface generation" idea sounds nice, but in the end, you bring in the same problems not as errors in the code, but as errors in the interface specification. Typically, they end up having even more serious problems, because typically, they are much harder to fix.

      I do not advocate to use direct memory (or hardware) access routinely. (Personally, I have currently standardized on Python3 as glue and logic and C modules to do the heavy lifting wherever that brings significant time or space advantages.) But I do not believe that a language can be both made efficient and memory-safe. It has been tried numerous times before and always did run into fundamental problems. And each time, the proponents of the new thing said it would solve all those problems. It never did or only at far too high a price (excluding special cases). At the systems programming level you need the control and the efficiency and you do not get them with memory safety or hardware-access safety for that matter. Not doable, unless we get working true AI at some time. The problem is than in order to know what is safe, it is is required to understand what the software is doing. No compiler can do that.

      However, I do not see any fundamental problem with this. I do see the problem that the parts in the systems programming language have to be kept minimal, and that somebody really competent has to do them. Both things are unfortunately often not the case today. The GNU libc, for example, has suffered significantly from the arrogance and incompetence of Ulrich Drepper. (I know him. Very smart, but thinks he is even smarter than he really is and that is the problem.) Fortunately, he is gone now. If done right, the functionality of GNU libc will be kept stable for a long time and at some point there will not be any significant problems left. That is the only way to do it. Writing this thing new, like musl attempts to do, will fix some problems with glibc, but will introduce a host of new and surprising defects instead. That is not a good idea at all.

      I do know that there is a school of thought that thinks coding is easy and you just need the right language and everybody can do everything. Having taught coding to a few hundred people academically, I do not believe that is the case at all. It is a specific talent people need and it requires at least a decade to get good at it. I have seen people fail CS after trying for 2 years because they could not hack it, and then go on and do a good Master's in Mathematics, so it is not intelligence or structured thinking what they lack.

      The other thing is that a language is always a trade-off between safety and power. It must be in this universe where performance is the limit and not computability. The RUST proponents are just the latest in a long, long string of movements that do not understand that. Their idea has been tried so many times, that the most serious criticism of RUST is that its proponents do not know or do not understand the history of computing. Their arrogance does not help either, but their fundamental failing is that they make claims that are _known_ to not hold up and have been known to not be feasible for a long time. Hence they separate their audience into two classes: The bright-eyed naives that are unaware what has all been tried without success and think this may be the great shiny silver bullet and those a bit more grounded in reality that see that what they claim is actually not achievable, at least not today.

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
  22. Indeed by Anonymous Coward · · Score: 1

    That works 100% of the time except when Bad Guy has written a little evil Perl script to iterate over all servers of your Linux shitfarm.

    Or in case of this bug, if bad buy has taken out a poisoned ad on NY Times, attacking your glibc DNS craptastica.

  23. Free Advice by Anonymous Coward · · Score: 0

    Don't use SSL. There is NO correct implementation of this crapola available. It simply is too complicated.

    Use a symmetric block cipher (e.g. 3DES) and symmetric keying and be done with it. Not perfect either, but you can implement it yourself and comprehend what it does.

    Send keys by enveloped snail mail.

    SSL/TLS is the siren song of the Dark World.

  24. NOT by Anonymous Coward · · Score: 0

    See "free advice" above.

  25. FALSE by Anonymous Coward · · Score: 0

    OpenSSL clearly was a shitty hairball with a clear objective of making the crypto effectively easy to break.

    Dumping OpenSSL, dumping SSL in general and using simpler approaches (e.g. symmetric cipher and symmetric keys transported by snail mail or couriers) is the Way To Go.

    IT people are often so deeply stuck in problems so that they cannot see the obvious solution. And 99,9% of IT people are gullible idiots. While believing to be exceptional.

    1. Re:FALSE by Anonymous Coward · · Score: 0

      Let me guess, you consider yourself one of the .1 % that are *actually* exceptional.

  26. You Mean Cyber Gun Control is Bad ? by Anonymous Coward · · Score: 0

    Yeah, it makes the work of certain war industry folks harder, we know the "cyber war domain" is great business for you.

    I am all for eliminating your nice little Business Domain.

    But i concede you are excellent at bullshitting the world into your game. And you are excellent evil strategists. C and Unix could hardly be more evil and more conducive to your evil Bu$$ine$ Plans.

  27. Chrome still exposes real IP via webrtc by Anonymous Coward · · Score: 1

    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.

  28. Nice, no stupid name for this one by Anonymous Coward · · Score: 0

    It seems that the ridiculous meme with giving vulnerabilities stupid names has finally stopped or maybe the hipsters are on vacation?

    CVE-2015-7547 is all we need. This is how it would have been before:

    Stupid name: GlibcBeMyValentineShock

    Social media profiles for GlibcBeMyValentineShock:

    Facebook
    Snapchat
    Tinder
    Grindr

  29. Wait a second... by Anonymous Coward · · Score: 0

    The GNU C Library has a DNS client built in? I'm not even a programmer and I think that that's retarded.

    1. Re: Wait a second... by Anonymous Coward · · Score: 0

      So where do you suggest it go? The C library by definition depends on nothing more than the kernel so I guess we could put that in the kernel.

  30. sudo does network access? by Anonymous Coward · · Score: 0

    The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl.

    Holy crap, a workaround for stupid Solaris 7 bug affecting the whole sudo community.

  31. Re:Anti-GPL bullshit by Anonymous Coward · · Score: 0

    Not true. Go read the book "More Guns, Less Crime: Understanding Crime and Gun Control Laws" by John Lott.

    And don't you find it odd that when muslim immigrants commit terrorist attacks or rape women and young boys, it's downplayed and we are told we musn't judge the lot of them based on the acts of the few and that we must support mass immigration of them regardless, yet when there's any kind of shooting it's evidence that we must immediately punish all people for the acts of a few?

  32. Avoid DNS security issues: How? by Anonymous Coward · · Score: 0

    APK Hosts File Engine 9.0++ SR-4 32/64-bit http://start64.com/index.php?o...

    -

    FREE, not 'souled-out' to advertisers, adds speed, security & reliability.

    Does far more w/ far less more efficiently vs. addons (clarityray blockable, redundant + RAM/CPU wasteful & 'souled-out' crippled by default) & local DNS servers @ home.

    Fixes DNS' security issues & stops tracking @ webpage + DNS levels via 1 file you NATIVELY have!

    (Firewalls do rest on FAR less used IP address trackers/threats vs. host-domain names).

    -

    Obtains data vs. online threats & ads via 10 reputable security community sites - easily edited by you using my program.

    -

    SPEEDS YOU UP 2 ways:

    Adblocking ALL ads + local RAM cached favorite sites @ TOP of hosts for faster resolution vs. remote DNS (for reliability + speed) vs. other "so-called security 'solutions'" SLOWING YOU!

    -

    All via what you already have vs. illogically "bolting on browser addons 'MOAR'" (clarityray detected/blockable + usermode slow & increased messagepassing, cpu + ram overheads)

    -

    MalwareBytes' hpHosts Admin (MalwareBytes employee verified it's source as safe http://forum.hosts-file.net/vi... ) hosts & recommends it -> http://hosts-file.net/?s=Downl...

    &

    MalwareBytes = BEST antivirus per a VERY recent testing of them all http://www.av-test.org/en/news...

    &

    It's safe proven by 57 antivirus programs in BOTH its 64-bit model https://www.virustotal.com/en/...

    +

    32-bit model https://www.virustotal.com/en/...

    &

    Installer-> http://f.virscan.org/APKHostsF...

    -

    * "The premise is quite simple: Take something designed by nature & reprogram it to make it work for the body rather than against it..." - Dr. Alice Krippen: "I am legend".

    APK

    P.S.=> By "yours truly" - "The Lord of Hosts" so-to-speak:

    "The image this title brings to mind is a mighty military commander who can at a mere word summon rank upon rank of protective power" -> https://answers.yahoo.com/ques... & THE WORD = hosts!

    (Accept NO substitutes)

    ...apk

  33. Avoid DNS security issues easily: How? by Anonymous Coward · · Score: 0

    APK Hosts File Engine 9.0++ SR-4 32/64-bit http://start64.com/index.php?o...

    -

    FREE, not 'souled-out' to advertisers, adds speed, security & reliability.

    Does far more w/ far less more efficiently vs. addons (clarityray blockable, redundant + RAM/CPU wasteful & 'souled-out' crippled by default) & local DNS servers @ home.

    Fixes DNS' security issues & stops tracking @ webpage + DNS levels via 1 file you NATIVELY have!

    (Firewalls do rest on FAR less used IP address trackers/threats vs. host-domain names).

    -

    Obtains data vs. online threats & ads via 10 reputable security community sites - easily edited by you using my program.

    -

    SPEEDS YOU UP 2 ways:

    Adblocking ALL ads + local RAM cached favorite sites @ TOP of hosts for faster resolution vs. remote DNS (for reliability + speed) vs. other "so-called security 'solutions'" SLOWING YOU!

    -

    All via what you already have vs. illogically "bolting on browser addons 'MOAR'" (clarityray detected/blockable + usermode slow & increased messagepassing, cpu + ram overheads)

    -

    MalwareBytes' hpHosts Admin (MalwareBytes employee verified it's source as safe http://forum.hosts-file.net/vi... ) hosts & recommends it -> http://hosts-file.net/?s=Downl...

    &

    MalwareBytes = BEST antivirus per a VERY recent testing of them all http://www.av-test.org/en/news...

    &

    It's safe proven by 57 antivirus programs in BOTH its 64-bit model https://www.virustotal.com/en/...

    +

    32-bit model https://www.virustotal.com/en/...

    &

    Installer-> http://f.virscan.org/APKHostsF...

    -

    * "The premise is quite simple: Take something designed by nature & reprogram it to make it work for the body rather than against it..." - Dr. Alice Krippen: "I am legend".

    APK

    P.S.=> By "yours truly" - "The Lord of Hosts" so-to-speak:

    "The image this title brings to mind is a mighty military commander who can at a mere word summon rank upon rank of protective power" -> https://answers.yahoo.com/ques... & THE WORD = hosts!

    (Accept NO substitutes)

    ...apk