Please create an account to participate in the Slashdot moderation system


Forgot your password?
Security Bug Linux

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."
This discussion has been archived. No new comments can be posted.

Bug In the GnuTLS Library Leaves Many OSs and Apps At Risk

Comments Filter:
  • by Anonymous Coward on Tuesday March 04, 2014 @06:04PM (#46401833)

    ...who has been surreptitiously using GPL'd code in their proprietary stacks...

  • by Carewolf ( 581105 ) on Tuesday March 04, 2014 @06:06PM (#46401867) Homepage

    Thank god it is in gnuTLS that is not used by any applications serious about security. Just checked, only printer drivers seems affected in my Debian installation.

  • by neiras ( 723124 ) on Tuesday March 04, 2014 @06:13PM (#46401963)

    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.

  • by williamyf ( 227051 ) on Tuesday March 04, 2014 @06:13PM (#46401967)

    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.


    • by rmstar ( 114746 ) on Tuesday March 04, 2014 @06:24PM (#46402097)

      Again one needs MOTIVATED AND QUALIFIED eyes AAAAAND good QA and test cases.

      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.

      • Since all machine code is potentially brittle, the argument for using "safety aware languages" is itself brittle. For instance, Ada is safe because it doesn't allow deallocation unless you use ada.unchecked_deallocation(), or in the alternate, build nothing on the heap, or just hope that the Ada implementation has garbage collection, or..., or... etc.

        _Someone_ has to do the work to protect whatever the brittleness is at issue.

        For years I have used "struct Buffer { char * start, char * end};" instead of just

    • by Zalbik ( 308903 )

      Damnit, it sounds like you are saying that software development is hard. And required diligence. And time.

      That is NOT what my pointy-haired boss wants to hear.

      He wants to hear that we can whip out software using cheap graduates of questionable schools, while distracting these developers with inane meetings, stupid corporate requirements (have you filled out you quarterly performance objectives?), and also making them the first-line software helpdesk and general IT support.

      And he wants it all yesterday.


    • ASIDE: Your point is mute [look up "moot" before attempting correction. 8-) ]. Enough is enough, and any less is not enough. That's the definition of enough.

      Consider: "If you eat enough pudding you'll die"... the only test case is to keep eating pudding till you die. If you stop before you die you didn't eat enough. 8-)

      Now the point that all eyeballs are not equal is fine and obvious. It only takes one metaphorical eyeball, connected to the correct brain, to find a bug. So one is enough if the rest of the c

    • Again one needs MOTIVATED AND QUALIFIED eyes AAAAAND good QA and test cases.

      And maintainers who will accept patches which fix these problems, and not reject them for bullshit reasons like not appreciating minor details of the code style.

  • by Frobnicator ( 565869 ) on Tuesday March 04, 2014 @06:15PM (#46401987) Journal

    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.

    • Re: (Score:2, Insightful)

      by Anonymous Coward

      "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.

      • by tepples ( 727027 )

        A connection with a MITM is not "secure". This is WORSE than sending data in plaintext.

        Plaintext protocols also have a MITM. How is it any worse?

      • What are you smoking? A connection with a MITM is not "secure". This is WORSE than sending data in plaintext.

        No, he is right. If the NSA is the man-in-the-middle, then you created a secure connection to the NSA, and the NSA will be friendly enough to create another secure connection to your original destination. It's not the secure connection you wanted, but it is secure. Nobody but the man-in-the-middle can listen in.

    • Your reasoning is a bit circular. This bug allows governments to do MitM attacks. Governments have already been doing MitM attacks, perhaps by exploiting this bug. Therefore, this bug is no big deal?

      SSL/TLS communications are just as secure as they always where, which is to say broken in a widely used library under an implementation/trust model is that is very widely used.
  • Code audits (Score:3, Interesting)

    by jones_supa ( 887896 ) on Tuesday March 04, 2014 @06:17PM (#46402007)
    I'm not sure if only "many eyes make bugs shallow" is enough, but that also professional, thorough code audits (like OpenBSD does) are needed to produce the most secure open source software. Any comments?
    • Re: (Score:3, Interesting)

      by Burz ( 138833 )

      Seems pretty clear that GnuTLS has too few eyes. Most everything uses OpenSSL instead, and that's where the eyes are concentrated.

  • by BasilBrush ( 643681 ) on Tuesday March 04, 2014 @06:18PM (#46402019)

    "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.

  • Testing is hard (Score:5, Interesting)

    by mveloso ( 325617 ) on Tuesday March 04, 2014 @06:27PM (#46402135)

    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.

  • Because if they were, the headline would have been zOMG mac and iOS not safe !!!!!!!11!!!!

  • Is everyone racing to change their passwords?

  • The coding error may have been present since 2005

    May it also be, the "coding error" was not an error at all, but a deliberately introduced bug? Government agencies always wanted to read our — and each other's — communications. Sometimes even for legitimate reasons...

    • Doubt it, GnuTLS is not really used for anything important.

      If you want a conspiracy, you can ask why OpenSSL still has insane defaults like allowing SSLv2.

  • by jbn-o ( 555068 ) <> on Tuesday March 04, 2014 @07:52PM (#46403073) Homepage

    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.

    • by cnettel ( 836611 )
      The Apple library itself was open source, right (although rebuilding the OS files would be precarious in OS X and outright impossible in iOS)? The mess with libraries like this (proprietary or not) is all other code (proprietary or not) that not only link to shared objects provided with the OS, but roll their own, sometimes even modified, build of the library. Now, thanks to the fact that it's GPL it cannot be hidden in a blob without at least a license notice, but tracking it down everywhere will be a mess
      • by jbn-o ( 555068 )

        Apple's code was based on something "open source" but that does Apple's users no good because of what I already said: Apple's distributed code to its users are proprietary. Better to have the alleged "mess" to track down than to know there's no point in tracking down anything because what you'll find is something you're not allowed to inspect, modify, or share. Here you're really highlighting the difference between free software and open source: open source advocates don't want to talk about how people ough

  • by MSG ( 12810 )

    So can we all get on the bandwagon with Fedora and start using NSS instead? []

Houston, Tranquillity Base here. The Eagle has landed. -- Neil Armstrong