Bug In the GnuTLS Library Leaves Many OSs and Apps At Risk 231
New submitter williamyf writes "According to this article at Ars Technica, '[A] bug in the GnuTLS library makes it trivial for attackers to bypass secure sockets layer (SSL) and Transport Layer Security (TLS) protections available on websites that depend on the open source package. Initial estimates included in Internet discussions such as this one indicate that more than 200 different operating systems or applications rely on GnuTLS to implement crucial SSL and TLS operations, but it wouldn't be surprising if the actual number is much higher. Web applications, e-mail programs, and other code that use the library are vulnerable to exploits that allow attackers monitoring connections to silently decode encrypted traffic passing between end users and servers.' The coding error may have been present since 2005."
AHAHAHAHAH (Score:1, Insightful)
"Open Source Software is more secure because the code can be reviewed."
That's why this bug has existed since 2005. gg, guys. Thumbs up.
Now we'll find out... (Score:3, Insightful)
...who has been surreptitiously using GPL'd code in their proprietary stacks...
Re:First (Score:4, Insightful)
First, and yet another OSS-releated security risk :(
At least they are rare enough that it is news worthy. As compared to Windows where new exploits hardly ever get any attention because they are so frilling common as to be passé.
Re:With enough eyes... NOT (Score:4, Insightful)
Perhaps using a safety aware language like Ada would be helpful too. C is known to be brittle, yet people insist in writing all sorts of mission critical code in it. I really wonder why.
Re:Now we'll find out... (Score:4, Insightful)
...who has been surreptitiously using GPL'd code in their proprietary stacks...
Why would anyone bother when they could just use OpenSSL and not have to worry about it?
Re:Severe, and yet not severe. (Score:2, Insightful)
"The connection will still be secure, it will just be with an untrusted person."
What are you smoking? A connection with a MITM is not "secure". This is WORSE than sending data in plaintext.
Re:Different Software - Same Problem (Score:3, Insightful)
Yeah, force people to write a big pile of nested bracket spaghetti and manually back their way out of every case. Make them introduce a bunch of otherwise useless flag variables and extra conditional statements to keep track of it all.
The best part of it all: When all that extra obfuscation causes bugs, it would be harder to pin the root cause on a simplistic generalization like "goto === bad".
Re:AHAHAHAHAH (Score:2, Insightful)
How is this insightful? The only way this could be insightful is if the OP had said "This bug has existed since 2005, clearly we need greater adoption of open source software, to get more people interested in testing for bugs", because the option is closed software that has bugs no one can look at or fix.
I already have the the security update to this bug on all my machines, but if I had closed source who know when, if ever, a patch would have come.
Bug was NOT found due to being open source (Score:2, Insightful)
This bug wasn't found from being open source. Those "many eyes" missed this bug for nearly a decade. Security testing tools uncovered incorrect validation behavior in the compiled library, just like they would with a closed source library. The only difference is that the public can see the incorrect code and correct it immediately; that is what you should be citing as an advantage of open source.
Re:Moderation (Score:0, Insightful)
To the moron who mod'ed this off topic: rot in hell you nazi prick.
Re:Different Software - Same Problem (Score:3, Insightful)
Wow, have you ever actually written production code? Just wow.
There's nothing cleaner than
if (input1 == null) {
return ERROR("input1 was NULL");
}
if (input2 == null) {
return ERROR("input2 was NULL");
}
if (input2 == null) {
return ERROR("input3 was NULL");
}
Substitute "throw new ERROR(..)" or "goto :error" depending on what kind of code your writing, it's the same thing any way you do it.
Nesting three levels deep before you even start to write real code? Garbage.
Re:AHAHAHAHAH (Score:5, Insightful)
That may be, but once the behavior was observed, the observer didn't have to find the owner of the code to get it diagnosed. They may have, but the point is that anybody who found this behavior could've gone into the code and found out what caused the problem. Of course, if a black hat happened to be the one that found the bad behavior, they could've gone into the code to figure out how best to exploit it. So, the situation's not perfect, but still, it's probably a good thing that there were lots of eyes allowed to diagnose and fix the problem once it displayed itself.
Freedom is better than dependency. (Score:4, Insightful)
So when Apple's proprietary encryption software suffered a problem, Apple users could do nothing but wait for Apple to deliver a fix; there's nobody else that are allowed to fix Apple's proprietary software but Apple. And when that fix ostensibly arrived, Apple users had to hope it wasn't bundled with some malware too (as is often in proprietary software [gnu.org]).
This bug was caught during an audit [gnutls.org]—"The vulnerability was discovered during an audit of GnuTLS for Red Hat.". Nobody but the proprietor can audit proprietary software. But with free software, users have the freedom to audit the code they run, patch that code, and run their patched code; users can choose to fix bugs themselves or get someone else to fix bugs for them. And users don't have to always trust the same people to do work on their behalf. Users can also choose to wait for a fix to be distributed, and then they can choose to check that fix to make sure it doesn't contain malware. For all we know some users have long spotted and fixed this bug in GNUTLS. Since all complex software has bugs bugs are unavoidable. We're better off depending on people we choose to trust. Software freedom is better for its own sake.