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.)
" - 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 ^_^
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.
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 :)
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."