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.
Yet another call for replacement... (Score:5, Insightful)
... because the proposed replacement will be bug-free, right?
Re: (Score:3, Insightful)
Re: (Score:2)
I was thinking this was another push to get off of GPLv3 code (like clang vs gcc), but it looks like glibc is LGPL.
Re: (Score:2)
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
Re: (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.
Re: (Score:2)
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...
Re: (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
Re: (Score:2)
Re: (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.
Re: (Score:2)
who is paying you for your evil words ?
or is it just the common devil worshipping of your culture?
No, that's the other [freebsd.org] BSD :-)
And when it comes to our operating systems of choice, it's not a religion. Far more faith than one.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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...
Re: (Score:2)
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.
Re: Yet another call for replacement... (Score:3)
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
Re: Yet another call for replacement... (Score:5, Funny)
He immediately awarded the prize to the second woman.
Systemd?
Re: (Score:2)
Re: (Score:3)
BLISS - used to program OpenVMS.
Re: (Score:2)
haha you are funny. BLISS had no I/O, that was all external calls. Guess where more vulnerabilities come into play?
Re: (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:
is BLISS for
Bye bye memory safety.
Re: (Score:2)
you misunderstand, C has standard functions for I/O, BLISS does not
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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...
Re: (Score:2)
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.
Re: (Score:2)
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. Th
Re: (Score:2)
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
Eh? (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?
same bug crashes same way on both machines (Score:5, 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.
Re: (Score:2)
Re: (Score:2, Insightful)
systemd's own resolver is still dealing with decade old bugs like spoofed responses and poisoning attacks.
Re: (Score:2)
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/... [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.
Bitcoin? (Score:2)
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)
Indeed (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.
Re: (Score:2)
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?
Re: (Score:3)
That function is used a lot.
Re: (Score:3)
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.
Re: (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?
Re: (Score:2)
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)
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.
Re: (Score:2)
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.
Re: (Score:2)
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).
Re: (Score:2)
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.
Re: (Score:2)
I think it's just timothy trying to inject some eye-catching words in the headline for click-baiting.
And this is why I insist on Windows 10 (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.
Instead of bitching, get a list of fixed versions. (Score:2)
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?
Re:Why does a C library need a DNS client? (Score:5, Informative)
Doesn't the operating system already have one?
Yeah it has one, the one in the C library.
Saved by rust again (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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (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
Vindicated again! (Score:2)
Ha! I knew procrastination would pay off! Debian Lenny has libc 2.7, and so is not vulnerable.
*gloat*
Chrome still exposes real IP via webrtc (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.
Re: (Score:1)
They do fund quite a bit of it. In this particular case the glibc maintainer works for Red Hat.
Re: (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?