Slashdot Mirror
Serious Network Function Vulnerability Found In Glibc
An anonymous reader writes: A very serious security problem has been found and patched in the GNU C Library (Glibc). A heap-based buffer overflow was found in __nss_hostname_digits_dots() function, which is used by the gethostbyname() and gethostbyname2() function calls. A remote attacker able to make an application call to either of these functions could use this flaw to execute arbitrary code with the permissions of the user running the program. The vulnerability is easy to trigger as gethostbyname() can be called remotely for applications that do any kind of DNS resolving within the code. Qualys, who discovered the vulnerability (nicknamed "Ghost") during a code audit, wrote a mailing list entry with more details, including in-depth analysis and exploit vectors.
The libc -> glibc switch was so much fun, that I think we should do it again in reverse!
I don't get it. Proprietary software has all sorts of serious vulnerabilities. Why is it that when a vulnerability is found in FOSS, you people all come out and mock it while ignoring all the incompetence of proprietary software?
FOSS *is* more secure, and that's true even with the occasional vulnerability. You're extremely illogical to point to some vulnerabilities and conclude that it isn't more secure. How many vulnerabilities are not known about because no one can look at the source code?
So long as we're writing in C, this kind of thing (buffer overflows in particular) will probably continue.
(Lest I start a flame-war: C is awesome in its way, but more than almost any other language, it really does make it easy to miss things like this.)
I don't get it......Why is it that when a vulnerability is found in FOSS, you people all come out and mock it while ignoring all the incompetence of proprietary software?
I see that this is your first visit to Slashdot. Welcome!
Give a man a fire and he'll be warm for a day. But light a man on fire and he'll be warm for the rest of his life.
How many years was Heartbleed around before anyone noticed? Apparently "many eyes" were not reading that bit of code.
Only the State obtains its revenue by coercion. - Murray Rothbard
" - We identified a number of factors that mitigate the impact of this bug. In particular, we discovered that it was fixed on May 21, 2013 (between the releases of glibc-2.17 and glibc-2.18). Unfortunately, it was not recognized as a security threat; as a result, most stable and long-term-support distributions were left exposed (and still are): Debian 7 (wheezy), Red Hat Enterprise Linux 6 & 7, CentOS 6 & 7, Ubuntu 12.04, for example. "
So it's actually already been fixed. All that's needed here is for some distributions to push the fix out.
f u cn rd ths, u r prbbly a lsy spllr.
I am suspicious of any C coder (myself included) who does not acknowledge this basic problem ^_^
The affected call is gethostbyname() and friends, which have been deprecated by the more protocol-transparent getaddrinfo()/getnameinfo() set of APIs. If you use IPv6, getaddrinfo() is the only way (gethostbyname() and friends are AF_INET (IPv4) functions only), but they're protocol transparent ways to do DNS lookups (they can return AF_INET, AF_INET6 and any other valid address supported by the system and DNS).
Deep down, if you look closely, they mention that code using getaddrinfo() is not vulnerable to the bug.
Shortly after learning about getaddrinfo() I stuck to using it - far easier to use than gethostbyname() and less messy in the end. The only complication is having to call freeaddrinfo() when you're done.
However, it's not like gethostbyname() is a rare call. I suspect that well over 99% of net-aware applications are still using it. This affects just about everything that's talking over the internet.
Religion is the best example of mass psychosis
Don't be so glib, see?
I'll be here all night folks. Tip your servers. Make sure they're bolted in, though.
If you were me, you'd be good lookin'. - six string samurai
In case you're unaware, "bugs are shallow" doesn't mean they don't exist.
ESRs complete sentence is:
"given enough eyeballs, all bugs are shallow; or more formally: Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone."
In other words, someone will quickly quote Adam Savage and say "THERE'S your problem!". :)
The difference between a deep bug and a shallow bug is is what happens after you notice a problem. A shallow bug is right there, at the surface. Function foo() is supposed to return x, but instead it returns x -1, and there is the line of the code that's the problem.
A deep bug is one where you look at function foo(), which creates an instance of class Bar, which is subclassed from IEParser, which calls friend class HTML4Lexer, which has function TagAtrribute() - but TagAtrribute() returns the correct value, so how the heck is it wrong in Bar? Then when you found out WHY it's wrong, you can't come up with any way of fixing it without rewriting the HTML specification.
Heartbleed is actually a great example. Many people looked at it right away and within an hour or so there was a patch available. Those may people discussed the three or four proposed long-term solutions and in about 24 hours we agreed on that Florian's solution was best. Florian was one of the many eyes, and the bug was shallow to him - "he fix will be obvious to someone", and that someone was Florian.
There must be agencies seeding these projects, commercial and open source, with toxic contributors injected there to deliberately contaminate the code with such bugs. The further fact that one never sees responsible persons identified, removed and blacklisted suggests that contamination is top down.
Or, you are yourself a toxic seed planted by The Man in order to foment FUD and make good people not want to be part of these projects. Or something like that. Give it a rest with the absurd conspiracy crap.
Don't disappoint your bird dog. Go to the range.
FOSS *is* more secure, and that's true even with the occasional vulnerability.
Loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooool.
Its true *ESPECIALLY* with the occasional vulnerability because thats a vulnerability thats been found, publicised and fixed unlike in the proprietary shit where the vulnerability will be found by a limited group of people and kept secret so they can use it.
In the free world the media isn't government run; the government is media run.
Never attribute to malice that which is adequately explained by stupidity.
There are too many stupid people in the world. Stupidity isn't necessarily a permanent thing: it could be caused by time constraints, personal problems or even lack of/too much caffeine. Or just because one doesn't think of the problem from start to finish.
But then this could be what "they" want you to believe :)
--
no sig for you. come back one year.
According to directions side-thread, glibc versions prior to 2.19 are vulnerable. Checking my machines, Slackware-current and Lubuntu-14.10 are fine. Only my poor tiny Raspberry Pis are vulnerable (2.13). But they run slowly enough I can watch the gethostbyname() lookups myself :)
People who think that Java (or C#, or Python) language will fix their security problems write more security bugs than C programmers who work around the weaknesses of their language.
Similarly, people who think Java (or C#, or Javascript) will fix the problem of memory leaks, are probably leaking memory all over the place. Recently I've been fixing a bunch of memory leaks in Javascript.....if you attach something to the DOM, make sure you have a plan for getting it off, otherwise you're probably leaking.
"First they came for the slanderers and i said nothing."
FOSS *is* more secure, and that's true even with the occasional vulnerability.
Loooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooool.
Its true *ESPECIALLY* with the occasional vulnerability because thats a vulnerability thats been found, publicised and fixed unlike in the proprietary shit where the vulnerability will be found by a limited group of people and kept secret so they can use it.
Oh, you mean those nice folks over in Eastern Europe?
and the intelligence network of the 5 main english speaking nations...
In the free world the media isn't government run; the government is media run.
Current glibc release is 2.20. That's three relases without the bug already.
Nothing to see here, move along.
True, but gethostbyname() is ancient and if the program wants to support IPv6, you can't use gethostbyname(). So I think the number of programs actually vulnerable is far lower. Remember, gethostbyname() only works with AF_INET - while getaddrinfo() works with AF_INET, AF_INET6 and any other protocol that uses sockets (since it returns
making life really easy).
So a lot of older code is vulnerable, newer code less so. it's been around about 15 years or so.
Your assumption is only one person did an analysis.
Do you have any idea how many people have combed over glibc and either reported or exploited issues found?
Hell, read the article - THE PROBLEM WAS PATCHED before he found it. What we're talking about is some old distros are still distributing that code unpatched, and that's the real problem.
We can all jump to conclusions but, personally, I doubt the NSA have anywhere near the capabilities they (and you) suggest. These people are in the art of deception. They don't need to crack something, they just need to make you think they have.
In the grand scheme of things, any secure system is out of their reach anyway, whether it uses this code or not. The systems they're interested in are likely running under much more strict scrutiny and a single attempt to exploit such things would raise alarms and even accusations of initiating cyber-wars.
To be honest, I'll put my trust in a planet full of people checking open code casually than a select group of "experts" hunting out these flaws.
People are being paid, worldwide, to find and fix these flaws in major commercial companies and just as security researchers, in universities or for their own personal reputation.
Next, we'll be in the "acres of supercomputers" and "boxes in every ISP" bollocks. You know what? If I were the NSA, that's EXACTLY what I'd want you to think.
They're either incompetent (fucking up Elliptic Curves in public forums and being spotted instantly), or they're not (in which case you can't believe anything they say and likely won't know what the REAL trick is).
Managed languages (like Java and C#) give you a "secure-by-default" memory and execution model that's a lot harder to accidentally mess up.
If you think managed languages will prevent you from leaving security vulnerabilities, you are either not writing significant server software, or your software has vulnerabilities.
.Net is especially bad in this regard, not because C# is inherently more insecure, but because the community applauds and encourages ignorance, and even makes people feel bad for knowing things. See this presentation for an example. Notice (for example) his micro-agressions against people who understand garbage collection. The implication is you don't need to think about it, C# will take care of memory.......which if you take seriously, means you'll be leaking crap all over the place and someone like me will have to come clean it up for you.
The hardest security problems to solve aren't the overflows, it's the features given to users. Think of VB macro viruses, that spread wildly in a managed language. Wordpress is another example of software written in a managed language with tons of exploits.
There are so many examples of exploits in managed systems that it's a display of ignorance to claim otherwise.
"First they came for the slanderers and i said nothing."
As pointed out in the article, the program must use gethostbyname() on a name supplied by the attacker.
A much more mitigating factor is that the bug is only exercised if the name looks like a numerical id, and according to their search most software first checks this using inet_aton() and only calls gethostbyname() if this fails, thus avoiding the bug.