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."
With enough eyes... NOT (Score:5, Interesting)
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
Code audits (Score:3, Interesting)
So much for Linus's law. (Score:5, Interesting)
"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.
Re:Waiting for Microsoft's "Goto Fail" (Score:5, Interesting)
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.
Testing is hard (Score:5, Interesting)
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.
Re:AHAHAHAHAH (Score:5, Interesting)
"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... [computerworld.com].
Re:Code audits (Score:3, Interesting)
Seems pretty clear that GnuTLS has too few eyes. Most everything uses OpenSSL instead, and that's where the eyes are concentrated.
"Error" is Plausable Deniability (Score:5, Interesting)
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...