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.
And can be audited by anyone anytime, so it is more secure... Ohh, wait
There's lots more information at my site http://dsfnjsaxshnc-lmachine7.... ...
You are not alone. This is not normal. None of this is normal.
The libc -> glibc switch was so much fun, that I think we should do it again in reverse!
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
Microsoft never developed the integrated "on error - SHIP IT" compiler options.
" - 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.
Here's some rope, be careful lest you hang yourself.
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
I don't think so. There are just too many of these buffer overflow security holes in commercial and open source software to be a chance. In over two decades of programming in every language and platform that came along, from Z8, x86 assembly, then FORTRAN, C, Pascal,... Java, Javascript, Python, awk, objective C, ... from embedded coding on routers, switches and misc. controllers, to numerous versions of MS DOS, Windows, Linux and iPhones, I have yet to have one such buffer overflow bug in my code. It's the most basic rule to check for buffer boundaries that even beginner programmer learns it quickly.
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.
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.
The article lists a long string of mitigating factors tat make it not as dangerous as it might first appear. Someone else already mentioned that it doesn't effect applications that are IPv6-ready; both IPv4 and IPv6 addresses are resolved with the same (safe) function in most software that's IPv6-capable.
Also, at 4 bytes can be overwritten on 32-bit, 8 bytes 64-bit, and they can only be overwritten with ascii digits 0-9, dots, and must have a terminating null. (So really three bytes on 32 bit, 7 bytes on 64 - not enough for a pointer).
There are several other mitigating factors. You should update glibc, but there's no need for panic.
This has me more concerned than some of the other recent bugs, primarily because it's so easy to exploit by script kiddies.
Plus, there are huge, vast, barely conceivable numbers of network-attached embedded devices that use the gethostbyname() call. What percentage of these are remotely update-able? What percentage of these will have their firmware re-flashed?
This one seems like it gives black-hats the ideal way to get a swarm army of (relatively) weak and/or dumb devices. Yet even these weak, dumb devices should be sufficient to set up warrens of ssh tunnels, nodes for DDoS attacks, etc.
Yuck.
Eloi, Eloi, lema sabachtani?
www.fogbound.net
According to the second link, the buffer overflow occurs when using a strcpy;
resbuf->h_name = strcpy (hostname, name);
In my (admittedly limited) recent c coding I've used strlcpy rather than strcpy. Is there a good reason not to use this (or strncpy) in place of strcpy?
resbuf->h_name = strlcpy (hostname, name, sizeof(hostname));
(OK, you may get an error due to a truncated copy, but isn't that is easier to spot and deal with than a potential buffer overflow?)
You never know what is enough unless you know what is more than enough. - Blake
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.
I suspect that you are an idiot. Only the Linux crap has this vulnerability. Enlightened OSes that avoid glibc like the plague that it is don't have this vulnerability. I'm pretty sure "not Linux" has more than one percent market share.
Glibc is the number one reason I don't use Linux.
Was it released prematurely?
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 :)
The fix has already released
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.
One person does an analysis, finds serious bug.
Now think about the NSA budget and how many people they can hire to look through code 24/7, and you'll understand that literally everything has already been hacked at this point. Tor also has been broken 10 times over. Every now and then us regular folks, like the guy from this article, find a problem.
RMSDS - Richard M Stallman Derangement Syndrome - A mental illness suffered by many on slashdot, who take it out on anyone else who has anything positive to say about the genius and amazingly successful RMS. You guys are fucking idiots. Stallman's creations and accomplishments will be celebrated for centuries to come, but you were never known and the pizza guy has already forgotten you.
#pragma warning( disable: XXXX) // The compiler was just kidding, but it won't compile unless we ignore its jokes.
void *strcpy() { printf("Don't use strcpy, idiot! We told you that years ago!\n"}; exit(-37); }
void *strcmp() { printf("Don't use strcmp either, idiot! We told you that years ago too!\n"}; exit(-37); }
Also, according to the articles I've read about this, the somewhat more official patch came out in 2013, but wasn't marked as a "security" patch so it only made it into the newer OS versions, but wasn't retrofitted into the older ones. So it'd be fixed in Ubuntu 14.04, but not in the 12.04 LTS version.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
There is not way this has to do with the fact we are still using millions of lines of C.
In case you're unaware, "bugs are shallow" doesn't mean they don't exist.
Everyone's aware of that. Nice strawman, though. The issue is that FOSS advocates constantly promote the idea that FOSS has fewer bugs due to those "many eyes", neglecting the fact that many of those eyes aren't looking and can't see very well. It's nothing more than propaganda.
That's somewhat true, their exploit will show how to exploit EXIM if that's installed and open via the firewall on vulnerable systems. Most other software using glibc isn't vulnerable for the reason I listed above.
Also,with 3-7 bytes they can overwrite, less than the size of a pointer, their exploit may be very, very limited. Specifically, it can't specify a memory address to jump to where the main exploit is found, because there's not enough room for a pointer to a memory location. We'll see what they come out with, but it may well be very, very limited.
CentOS 4,5,6 == Vulnerable (Upgrade to CentOS 7)
Legacy EC2 Linux instances == Vulnerable (Upgrade to CentOS 7)
Latest Astaro Firewall (http://www.astaro.com/node/11351) == Vulnerable
Latest QNAP embedded appliance (totally unmaintained port) == Vulnerable
Compiling glibc is not a joke, this ain't your easy bash SHELLSHOCK binary build.
It normally involves re-installing the entire server, plus all its customization,
assuming you can still get SysVInit rc.d boot script to port such customization...
This is a complete nightmare...
Plus most providers have no binaries available.
They better not release the metasploit until everyone has working patches, including legacy boxes!
For every other topic, you use custom icons for the stories. Horrible custom icons most of them, but still....
Yet for GNU stories.... oh nooooo.... you insist on using the original artwork for that... that....THING. Not sure what they call it.... that smiling..... THING.
Why, Slashdot, why?
Once again, the pr horny whitehats ar4e a decade late. This bug discovered over 12 years ago frmo a eggdrop process that ektp crashing while doing processig on a speciific reply in their dns resolver. somewEre bewween eggdrop 1.1.5 and 1.6.x i COould say, i forget. point is. i see your GHOST and raise you my ghostintheshell.c. if you need to verify this i'm sure the eggdrop lackey who leaked the info to thde v tea, he got fmor hanging out with actual programmers can confirm.
you ppl have no clue how blissfully ignorant you all are. good thing we still have a fe wo these decade ++ old ones left but this is getting annoying :)
Solar Designer: you should fucking know better. You should
why do you seek the limelight so hard whitehats? IT'S ONLY TEMPORARY AND THE LONG run does not favour any of us.
that does not matter. i am happy for you to have allt the spolt ight. it is dangerous.. just wait.
and here i thought we showed you morons in 2009 how amateur you are when our courier walked in and took your awards *using tha remote kenrel exploit everyone sayd couldnt be done remember?)leaving you your inboxes in print. i think a certain someone still owz 2 session cookies, or did we hallucinate that
defcon/blackhat event?!
So from the bottom of my heart to to the en of a hammer: fuck you fore ver thinking you can kep up with us.
That's what they get for using double underscores in function names.
Table-ized A.I.
when will people learn? if you actually want software from devs that give a crap about security use openbsd. for anyone that's actually looked behind the curtain of gnu software: it's a total horror show.
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.
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.
Custom electronics and digital signage for your business: www.evcircuits.com
Go open sores! Many eyes! Shallow bugs! Woo! open sores!
Must be late or too tired because I can't make sense of this. In the test program, he does:
size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1; /usr/sbin/clockdiff `python -c "print '0' * $((0x20000-16*1-2*4-1-4))"`
That makes sense to get around the size check and using the hostname of length len (without null) to overflow temp_buffer because of the omission of the alias pointer in the calculation. However, in the clockdiff example, he further subtracts the size of the pointer:
Wondering where the -4 comes in? If he does that, wouldn't the resulting string in fact fit inside the temp buffer?
I don't have a system with old enough glibc to run his examples at the moment. :(
You just reminded me why I don't like C++.
How exactly do you wish people to measure the number of bugs that didn't happen? This statement is reminiscent of discussions about the number of rapes or molestations that go unreported to police without realizing that "unreported" means that they're not reported and can't be counted accurately at all. Bugs are even more complicated because they are not one-shot events, they're errors that have a specific lifetime. If I 'git commit' a broken version of the software while I'm working on a large portion of it, then commit the remainder of the work that fixes it, was the broken version really "buggy?" Does it only count if it makes it to a numbered release? What about bugs that are in the code for weeks but included in no numbered releases? And how do you propose to gather accurate statistics on the number of bugs that exist but have not been found yet?
That's true, you could point to certain addresses. You're just left with no room to jump to that address or do anything else with it - the pointer takes up all of the space.
Also of course the other bytes of the pointer are restricted to eleven values each. I have no doubt they'll be some exploit, it's just likely to be rather limited.
A straw man is a position invented during an argument in order to strike it down. If I pretended Obama had proposed executing anyone who gets a promotion, then shown why that proposal is bad, that would be a strawman.
Pointing out what the original claim was isn't a straw man, that's the opposite of a straw man. Let me give you two more examples of straw man:
Bob: The water is shallow.
Sally: You're wrong, I can prove the water is wet!
Bob: The bug is shallow.
Sally: You're wrong, I can prove the bug exists!
Nothing on tor project website?
I'm sure if we wait long enough systemd will take over this function and we won't have to worry about it anymore. (There will stil be problems, they will just be labeled "won't fix", so fretting over it will be pointless). There should be a godwin's law variation for systemd.
Smart pointers are helpful though. Might've prevented this particular exploit.
Depends on what type of smart pointer we are talking about (as many people have shot themselves in the foot with them). There is a reason why std::auto_ptr is deprecated.
One really, but really has to understand a smart pointer lifecycle before using it to solve problems that can typically solved with careful programming practices, tests and liberal usage of tools like valgrind.
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.
In all legal ways to use the function, recognizing PATH_MAX == 256, is there a problem? So, it is a potential problem.
So, some library code was found that does not check for potential overrun. By broadcasting the routine name, hackers or ganifs will attempt to break into the system.
Why not just say, a new glibc has been released and fixes some serious bugs.
Leslie Satenstein Montreal Quebec Canada
Late comer, but in case someone is looking for this bit of information.
Just got latest updates. Before the updates I tested with this tool and result was vulnerable.
After the updates it reports "not vulnerable".
There was some messup with libc dev packages. I had to force uninstall some dev packages and do "apt-get -f install" a couple of times, until the problem cleared. This is most likely just my machine...
I should still reboot to make sure the old libc is not loaded in some processes...