Slashdot Mirror
Red Hat, Google Disclose Severe Glibc DNS Vulnerability; Patched But Widespread
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.
... because the proposed replacement will be bug-free, right?
-- I am. Therefore, I think!
"discovered independently by security researchers at Red Hat as well as at Google" - How does that happen, and when DID it happen?
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
BLISS - used to program OpenVMS.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
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.
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!
systemd's own resolver is still dealing with decade old bugs like spoofed responses and poisoning attacks.
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.
They do fund quite a bit of it. In this particular case the glibc maintainer works for Red Hat.
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.
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.
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
haha you are funny. BLISS had no I/O, that was all external calls. Guess where more vulnerabilities come into play?
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.)
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.
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.
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.
Doesn't the operating system already have one?
Yeah it has one, the one in the C library.
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.
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.
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?
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.
Ha! I knew procrastination would pay off! Debian Lenny has libc 2.7, and so is not vulnerable.
*gloat*
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.
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.
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.
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.
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.
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.
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...
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.
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.
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."
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."
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.
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.
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.
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.
Watch this Heartland Institute video
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!
you misunderstand, C has standard functions for I/O, BLISS does not