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.
Aw crap, Slashdot killed the joke. There was supposed to be an embedded "nc" command in that hostname.
You are not alone. This is not normal. None of this is normal.
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
Wat?
" - 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 ^_^
Let me inform you that C does not require buffer overruns to operate. The fast and loose easy implementation of C does. I've experimented with a different implementation of C for my VM that grows your stack upwards, places all function call frames on the heap, and isolates return code pointers from stack parameters. It is by far more secure than the GCC / LLVM / MSVC(++) implementations.
In my implementation: A buffer overrun doesn't affect the call stack. A buffer overrun writes into unused memory or causes segfault if it goes beyond the current allocated page. printf based stack manipulation simply screws with variable values, never code pointers.
It is the implementation that is to blame. I must avoid the x86 CPU instructions like ENTER and LEAVE or RET and CALL that assume I want code pointers on my stack, so the system runs slower. However, my point is that the CPU architecture itself was designed by morons who built in the stack smashing buffer overflow vulnerabilities by design, when they could have been mitigated by design instead. It was a different time then, but this is why we should ditch the legacy machine codes and design security in at the chipset level. FUCK YOU ARM for only having 1 bit of execution privilege rings, because with 2 or 4 as on x86 I can actually build secure OSs other than monolithic kernels: One ring for user/plugin separation, another for user/driver another for driver/kernel.
You blame the language for the hardware's fault. We should have MULTIPLE STACKS and ISOLATE THE CALL STACK FROM THE DATA. ISOLATE CODE AND DATA, this isn't rocket science, it's just dumb by design.
Yea we should write our system libraries in Go and Haskell. Maybe Coffeescript and run them all on node.js?
Get a clue.
Let me inform you that C does not require buffer overruns to operate. The fast and loose easy implementation of C does. I've experimented with a different implementation of C for my VM that grows your stack upwards, places all function call frames on the heap, and isolates return code pointers from stack parameters. It is by far more secure than the GCC / LLVM / MSVC(++) implementations.
In my implementation: A buffer overrun doesn't affect the call stack. A buffer overrun writes into unused memory or causes segfault if it goes beyond the current allocated page. printf based stack manipulation simply screws with variable values, never code pointers.
And I bet your implementation is slow as fuck.
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
When a FOSS hole is found... it is a hole... but not yet being exploited.
When we hear about issues with some closed source software, it is a 0 day, and the bad guys are already using it in the field as an exploit. IMHO, If the closed source stuff is "just" a hole, it sits unfixed until someone finds it and attacks become widespread.
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
Yes! Probably like Java.
The poster admits as much, but his point is still valid.
"File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
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.
> When a FOSS hole is found... it is a hole...
> but not yet being exploited.
You have no more reason to believe it's not being exploited than you do for a closed source bug. Just because you haven't heard about it doesn't mean that no one else has found it previously.
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.
"You people"?
Gee a little insecure are we? News flash software is software and has bugs. It doesn't matter which license it is under. It still is software and no being from Microsoft doesn't make it insecure by default anymore than being GNU makes it more secure.
Yes Apple, Google, and Microsoft are mentioned here when a serious flaw is discovered. Why should Linux or anything GNU get a free pass?
http://saveie6.com/
Well the thing is that FOSS people tend to be pretty derisive of the likes of Microsoft when problems are found in their software while smugly proclaiming that such problems do not exist in open source code. It gets kind of grating to those of us who are employed by companies to develop proprietary closed source software (yes that's right, we're sellouts)
Because C is cool and Java and flash suck. Get with the program
http://saveie6.com/
You can call that same function from within most other languages even without realizing you're doing it.
I'm pretty sure this vulnerability hits more server software than any openssl one ever did. Even software not written in C.
He's trying to tell us that he's really racist, and should be marginalized, but unfortunately he was too cowardly to post his name.
C is like a powerful table saw. Don't practice safety and know what you are doing and you lose a limb. Powerful but not all should play with one.
http://saveie6.com/
But heap overflows are just as exploitable as stack overflows. Stepping on all the program variables can be just as damaging as stepping on return pointers. Really, there's not much point in preventing that specific kind of overflow if you still allow the others.
Unless the FOSS hole was put there many years ago by a contributor specifically so it could be exploited.
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.
Why don't you just switch to a harvard based architecture?
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
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.
Hrm, can't argue with that logic.
People are stupid. Free software is merely a critical starting point for a system that aims to be secure.
You can call that same function from within most other languages even without realizing you're doing it.
It may be true that the vulnerable functions are called from other languages as well, but that does not necessarily mean these languages are also vulnerable. They may do sufficient memory management and/or parameter sanitation to avoid the vulnerability.
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
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 :)
C is like a powerful table saw. Don't practice safety and know what you are doing and you lose a limb. Powerful but not all should play with one.
Table saws have safety features that are not perfect but at least make it less likely to lose a limb. One could easily define a subset of C that also would make it far less accident-prone. Converting existing code to this subset would be painful but healthy.
So, you haven't really fixed all buffer overflows, but you've created an implementation of C that eliminates most of the advantages of C.
Why go to the trouble when you could have just used a language that is immune to buffer overflows?
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?
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.
C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off.
-Bjarne_Stroustrup, Creator of C++; cite
The fix has already released
Current glibc release is 2.20. That's three relases without the bug already.
Nothing to see here, move along.
It's because we've put up with 30 years of FOSS community trumpeting the fact that Linux isn't hacked, only Microsoft needs anti-virus, Open Source means that "something like this will never happen".
If a community spends decades puffing its chest and talking shit it's going to get 10x the scorn when it's revealed to be as vulnerable as the next guy. The fact is that all software can be hacked. And at any given time there is a zero day exploit that can probably penetrate any system. Commercial tools used to be the target of this research and and attack and now that open source is gaining traction it's getting the same scrutiny--and similarly failing.
Here's a tip. Best not to pontificate on something about which you know NOTHING.
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.
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.
Wrong. It is illogical to conclude anything without having all the data, saying FOSS is more or less secure is stupid and wrong. People can write secure and insecure (and there are varying levels of both) FOSS and non-FOSS software, the fact that there is the ability to look at the code doesn't make it more secure, all it does is all for the possibility to identify it as being insecure and fix it assuming you have the right people looking at the right places at the right time.
Neither is inherently more or less secure than the other.
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.
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.
Apparently, your experienced C developer is still leaving holes for arbitrary execution, despite all of the tools (fuzzing/NX/ASLR) targeting this specific issue. 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. The more "stuff" (languages, libraries, operating systems, etc.) that's secure-by-default, the less security holes we will have.
-1, Too Many Layers Of Abstraction
When a FOSS hole is found... it is a hole... but not yet being exploited.
Where do you get the idea that when a FOSS hole is found nobody is exploiting it? How do you even know when one is found? You wait for somebody to tell you about it and assume that nothing is ever found by anybody until then?
Here's a tip. Best not to pontificate on something about which you know NOTHING.
It's a nice tip. You should try to follow it. TFA talks about a heap overflow, did you read it?
#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
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."
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?
OP's comments are worthless because it cherry picks a specific example to speak about a general category.
Your comments are equally silly..
Dude, man that Big Mac was awwwwefulll... Mc Donald's blows...
Why is it that "you people" all come out and mock it while ignoring the equally awful food served at Burger King?
As if it the commenter had some kind of duty to enumerate their disposition to everything else just to be "fair".
FOSS *is* more secure, and that's true even with the occasional vulnerability.
This is a worthless generalization that may be true or false depending on quality of specific systems under comparison.
You're extremely illogical to point to some vulnerabilities and conclude that it isn't more secure.
What is basis for your assumption FOSS is automatically more secure just because it is FOSS? Please cite a study or statistical information supporting your assumption.
How many vulnerabilities are not known about because no one can look at the source code?
I give up... how many?
> So long as we're writing, this kind of thing will continue.
Fixed that for you!
People who don't actually work with core system functions would not *believe* the twisty path of scoped wackiness that tools like Java put on top of basic system functions. But oooh, wait!!!! systemd will fix all that!!!!
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.
Straw men, in other words. Show me someone who says that free/open source software means perfect security and I'll tell you they're an idiot in a very small minority. The actual claim is that it's more secure, not perfectly secure.
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!
You tried. Lots of people died, but the Union won the war. Trying again won't turn out better for you; you'll all die and your communities will be burnt to the ground.
The Civil War was a real thing. Us Americans are still willing to fight for our nation if you want to go that route again.
Because none of those systems let them play Murdering Hoes In Defense of Ethics in Journalism at the highest frame rate.
I'm actually trying to offload as many tasks as I can to network-connected microcontrollers using Harvard architecture. Given the importance of networking, it might make sense to move the whole application API to a dedicated Harvard chip. There is really no reason for things like gethostbyname to be frequently updated. And then the network processor can have a direct connection to the ethernet or other network chips. And if you need to update, you can just include an In System Programmer on the MB, and then you can update the network API firmware by connecting a cable on the board, allowing an updater to run on the main system.
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.
Stepping on all the program variables can be just as damaging as stepping on return pointers.
He's kinda right. Once a pointer goes off the reservation so to speak, anything can happen.
Let me know when you've made Java self-hosting.
This.
The thread here is chock full of dismissive comments as to why this FOSS exploit (like all the others) doesn't really matter. Except it does. They all do!
FOSS security holes:
'First they ignore you, then they ridicule you, then they fight you, and then you win.'
- M.K. Ghandi, time travelling into the future and grokking a subject he didn't even know about!
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.
Dude, I never thought of it that way. That is brilliant!
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.
Mod parent up!
There is no substitute for common sense. Especially, no body of rules will do.
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
To be fair, derision toward the likes of Microsoft has historically been pretty well warranted. Windows has, historically, obviously, been plagued by viruses, malware, crapware, etc., to a degree far surpassing any other operating system.
That's not to say this necessarily has anything to do with proprietary versus open-source. Obviously Windows has always been far more popular than any alternative, making it a much more tempting target for attackers. High profile bugs like shellshock have certainly pointed out that open source isn't a magical elixir that wards off security problems.
Nobody does security very well, yet. (Well, maybe excepting folks like the CompCert people and Sel4 people.) The underlying causes, I'm sure, is that it's not what your average (or even above average) consumer can evaluate and value, and it's not what your average programmer can deliver.
What language is the program written in?
Go open sores! Many eyes! Shallow bugs! Woo! open sores!
Oh, they don't need to look for the vulnerabilities. They put them in there!
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. :(
Take it for granted that every day, something needs to be mocked. If your thing isn't going to be it, then what will? Maybe they'll mock that other thing, the one nobody ever mocks?
Yes! We could call it C++ or something!
Oh, wait...
Not necessarily: to come to this point, you need two things: development quality, and auditing quality. The first to create, the second to discover, the bugs. The second is what you get plenty of, in the open source world, presumably. But you assume that an open source developer is just as good as a closed source developer. That might not necessarily be true.
Religion is what happens when nature strikes and groupthink goes wrong.
C++ also gives you many new and complicated ways to shoot yourself in the foot.
You mean JVMs? They're generally written in C++. No, this doesn't entitle you to grin smugly.
Although it's essentially impossible for a well-intentioned Java program to have a buffer-overflow vulnerability, the JVM itself is full of security bugs, so bytecode from an untrusted source generally shouldn't be executed.
To put that another way: the Java language has proven to be successful in preventing things like buffer-overflow attacks, but the JVM has proven unsuccessful in providing a secure sandbox in which untrusted code can be executed in a contained virtual environment. People tend to confuse these two distinct properties when they say Java is insecure.
If we wrote production JVMs in Java rather than C++, this wouldn't be a problem. (Yes, I'm serious. Unfortunately, it looks as though the most prominent such JVM, "Jikes RVM", will forever remain a research project.)
Does that affect your day-to-day work?
If you really want Java-written-in-Java, take a look at Jikes RVM.
I'm not terribly familiar with this particular exploit, but from the summary it looks as though it might have been avoided if they'd used automated reference-counting like C++ smart pointers.
Smart pointers are helpful though. Might've prevented this particular exploit.
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?
That is because all these people mocking FOSS have absolutely no clue, but try to elevate themselves by pretending to be smart. If they know how abysmally bad many/most commercial closed software products are (I have seen a few samples), they would think differently.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
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.
Hey, if your point is that too many PHB's and programmers think "managed" is a cure-all, I won't stand in your way. What I'm saying is that managed is a huge win for security.
The hardest security problems to solve aren't the overflows, it's the features given to users.
By contrast, the most common security problems are any situation where you silently expect the programmer to manually preserve some invariant (e.g, never allocate memory without a plan to deallocate it, never deallocate if anything else holds a pointer to it, never write to a buffer without checking bounds, etc.). Managed languages eliminate C/C++'s largest (and most critical) attack surface.
Now sure, I agree that they don't eliminate all attack surfaces. Security is hard. Java/C# have their own "manual invariants", such as always escaping/parameterizing SQL. ASP.NET Forms have a nightmarish arrangement where some controls/properties auto-escape HTML and others don't. Crypto primitives are widely available but poorly explained. Multi-threading is a minefield. But even here, the industry can eliminate the widest number of security issues using secure-by-default design. In C# for instance, EF/Razor/TPL make it (1) easier to accomplish programmer intent while also (2) making it harder to break low-level invariants.
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.
Office macros and PHP are some of the most hilariously bad designs in computing history. By necessity, any programming language worth its salt will let you make farcically bad decisions.
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.
As a Google developer, he can probably just throw clusters of auto-recycling web servers at the problem. Aside from opening avenues for DOS attacks, the consequences of this sort of problem (e.g., not knowing how your GC works) have more to do with performance/reliability than security (albeit the 3 are intimately linked).
Something we can probably both agrees on is that there's no substitute for knowing how things work. However, the reality is that most programmers don't care and even those who do have a limited mental budget for complexity. So there's also no substitute for being able to eliminate sources of complexity that are ancillary to the task at hand.
-1, Too Many Layers Of Abstraction
You know what you should run away from? Any large group of black people in America!
Fixed that for you.
Not every country is the same.
Managed languages eliminate C/C++'s largest (and most critical) attack surface.
Do they? Do you have data to back this up, or are you just guessing? Because from where I'm sitting, it looks a lot like the hardest security problems are the features you expose to users.
Something we can probably both agrees on is that there's no substitute for knowing how things work.
True, we do agree on this point. Although you contradict yourself at the end of the paragraph and try to come up with a reasonable substitute. When someone says "however" immediately after they say they agree with you........that's a strong sign they don't agree with you.
"First they came for the slanderers and i said nothing."
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
I love you.
Do they? Do you have data to back this up, or are you just guessing? Because from where I'm sitting, it looks a lot like the hardest security problems are the features you expose to users.
If you don't have to have any features, then yes, you can make your software very, very secure. :-)
The CWE publishes a list of the Top 25 Most Dangerous Software Errors which aims to "list of the most widespread and critical errors that can lead to serious vulnerabilities". You'll notice CERT tags their vulnerability announcements with references to the CWE when applicable.
Most are language-independent.... no surprise to see CWE-89 (SQL injection) and CWE-78 (command line injection) in there, as well as the slough of crypto/authN/authZ-related stuff. But where are the language-dependent bugs coming from? If you drill down on the code examples for CWE-120, -131, -134, and -676, you'll see C and C++ are a re-occurring theme.
You contradict yourself at the end of the paragraph and try to come up with a reasonable substitute.
No contradictions... knowing how stuff work is a training/educational goal (for programmers and those who teach them). Not having to know how stuff works is a design goal (for language creators, API writers, and designers in general). The former gives you insight, the latter gives you leverage.
-1, Too Many Layers Of Abstraction
Most are language-independent.... no surprise to see CWE-89 (SQL injection) and CWE-78 (command line injection) in there, as well as the slough of crypto/authN/authZ-related stuff. But where are the language-dependent bugs coming from? If you drill down on the code examples for CWE-120, -131, -134, and -676, you'll see C and C++ are a re-occurring theme.
Good then we're agreed, buffer overflows are not the most common security vuln.
All we need now is for you to realize that, if someone thinks the language means they don't need to worry about security, then their code will be much more vulnerable, even if they write in Java. Once you realize that, then we will be completely agreed.
"First they came for the slanderers and i said nothing."
In the cases you cite, you can get the same safety in C++, and you really should.
First, you use some discipline with pointers. Owning pointers are either unique_ptr or shared_ptr, which eliminates most memory leaks (not those in a circular structure, though), and makes sure that memory is neither double-freed nor used after it is freed.
Second, you never use C-style arrays. Use string and vector instead, and you've eliminated buffer overflows. Use .at() instead of [] (or make your own vector type that makes [] range-checked, as Stroustrup suggests), and you've eliminated wayward memory accesses.
This does require some discipline, but it's mechanical discipline. It doesn't require creativity, and it's easily checked in a code review because it's clear, mechanical, and messing up that discipline requires screwing up on an individual line of code in an obvious way.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
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...