Slashdot Mirror
Bug In the GnuTLS Library Leaves Many OSs and Apps At Risk
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."
...who has been surreptitiously using GPL'd code in their proprietary stacks...
From February 16 2008: Howard Chu of OpenLDAP: GnuTLS Considered Harmful
Looking across more of their APIs, I see that the code makes liberal use of strlen and strcat, when it needs to be using counted-length data blobs everywhere. In short, the code is fundamentally broken; most of its external and internal APIs are incapable of passing binary data without mangling it. The code is completely unsafe for handling binary data, and yet the nature of TLS processing is almost entirely dependent on secure handling of binary data.
Incredible that GnuTLS is used anywhere at all. It's just mind boggling.
I have always been critical about that conventional wisdom of "With enough eyeballs, all bugs are shallow".
I contend that is inacurate. With enough QUALIFIED AND MOTIVATED eyes, all bugs are shallow, and sometimes, some FOSS project lack enough Qualified eyes.
This bug, the KDE one, or even the Metafile bug in windows (and more importantly in WINE) among many others, show that many eyes are not enough.
Again one needs MOTIVATED AND QUALIFIED eyes AAAAAND good QA and test cases.
Cheers
*** Suerte a todos y Feliz dia!
The bug requires a carefully-crafted certificate. That certificate will verify as valid and trusted when it should not be. The connection will still be secure, it will just be with an untrusted person.
So basically it allows a very dedicated attacker to forge a cert and become a MitM attack.
We all know governments have done this for years. It is widely known that root CA certificates have been violated by spy agencies. A few searches on Google will show bunches of news stories where attackers (all types, government attackers, ID theft attackers, etc) have made fake certificates, abused the CA model, and engaged in similar MitM attacks to what this allows.
SSL/TLS communications are just as secure as they always were. If you have personally verified and trusted the certificates the attack wouldn't work, it is only when your trust model allows a cert that you don't personally trust to be used in authentication, and even then it still allows a secure connection but to a wrongly-trusted individual.
The flaw is the trust model and using a cert that you don't personally trust to be valid, which is a well-known issue.
//TODO: Think of witty sig statement
"given enough eyeballs, all bugs are shallow"
Apple had their goto bug in TLS for about 18 months before they spotted it.
GnuTLS and therefore Linux has had their goto bug in TLS since 2005 (9 years) and it's only been spotted now as a result of the bow wave from Apple's disclosure.
I think it was MS who had a bug in the past where if I got a certificate issues for "google.com\0.attacker.com", I could present that certificate for a request to "google.com" (due to DNS hijacking or a MitM attack) and it would pass validation because the CN was handled as a C-style string and treated the null byte as a terminator. Fixed long ago, but still. People have been messing up cert validation for as long as it's been around.
The scary thing is how many mobile apps just don't *do* cert validation. Either it's completely disabled, or they crippled it in some way (I've seen both not checking the trust chain and not checking that the cert is valid for the target site). The usual reasons are "oh, we just did that for testing" (but I'm looking at your release version...) or "yeah, one of the servers it connects to uses a self-signed cert" (fine, add explicit trust *for that cert* but don't just disable chain-of-trust checks!) Another common problem is leaving completely broken or outdated options enabled (export ciphers - 40-bit symmetric crypto, easily breakable with a home PC - ot SSLv2 or other such similarly stupid things). Even if your platform/framework/library has a perfectly bug-free TLS implementation, few people ever seem to actually use it correctly.
There's no place I could be, since I've found Serenity...
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é.
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
No the issue was with conditionals and braces. The same issue would have happened even if it were two return statements .
And a return statement before the end of a function is essentially a goto. A language that takes the step to rule out gotos should also not allow early returns.
Testing is hard. The tools you have make it even harder.
How do you build a bad certificate? Fuck, using the openssl tools is hard enough. Does anyone who uses them really understand WTF is happening? I know I don't - I just follow the instructions.
How would you go about building a bogus cert? Beats me. I'm pretty sure you can't do it with the standard tools. And who the heck is going to write their own cert building tools?
And yet, this stuff is at the core of transport security.
"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.
What do you mean? The many eyes found said bug that is why we are reading about it if thay had not it would still be sitting there undiscovered. Ever wonder how many bug go completely unnoticed in proprietary software because no one actually reads said code? Like for example a Windows bug affecting all 32 bit Windows OS's for 17 years: http://www.computerworld.com/s....
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
Next, you'll be coming for my trigraphs and pointers. My precious.
Hot on the heels of Apple's SSL/TLS implementation "flaw" across all stacks, and the Snowden revelations of NSA infiltration for weakening crypto?
You don't have to be wearing Tin Foil, just to become a little suspicious...
"Flyin' in just a sweet place,
Never been known to fail..."
It was a bug in multiple implementations of TLS including OpenSSL, NSS, and Microsoft's thing because they didn't expect cert authorities to give out certs with null bytes in the CN field.
This is why you should always roll your own SSL scripts in php like the guy at Magic the Gathering Online Exchange did.
Some drink at the fountain of knowledge. Others just gargle.
Yeah, force people to write a big pile of nested bracket spaghetti...
1. "nested brackets" (blocks) are by definition not spaghetti. Spaghetti is exclusively the result of gotos and their control equivalents (like the early return).
2. Nested blocks are refactorable into smaller functions. That's the way to cut them down to size, not to use gotos.
I mean really! People still trying to argue with structured code in 2014! You'd think it was still the 1980s.
The bug was found due to observed behavior, not due to a code review.
The OpenSSL license is not compatible with the GNU General Public License.
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.
Posted from my Android phone. Oh, I can change this? There, that's better...
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).
This bug was caught during an audit—"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.
Digital Citizen