Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Security Bug Linux

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

Posted by Soulskill
from the feeling-secure-is-the-biggest-bug dept.
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:
  • AHAHAHAHAH (Score:1, Insightful)

    by Anonymous Coward on Tuesday March 04, 2014 @05:01PM (#46401795)

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

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

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

  • Re:First (Score:4, Insightful)

    by lister king of smeg (2481612) on Tuesday March 04, 2014 @05:21PM (#46402071)

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

  • by rmstar (114746) on Tuesday March 04, 2014 @05: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.

  • by WaffleMonster (969671) on Tuesday March 04, 2014 @05:30PM (#46402179)

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

  • by Anonymous Coward on Tuesday March 04, 2014 @05:38PM (#46402271)

    "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 Waffle Iron (339739) on Tuesday March 04, 2014 @05:38PM (#46402275)

    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)

    by Anonymous Coward on Tuesday March 04, 2014 @05:42PM (#46402313)

    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.

  • by Anonymous Coward on Tuesday March 04, 2014 @05:58PM (#46402519)

    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.

    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)

    by Anonymous Coward on Tuesday March 04, 2014 @06:06PM (#46402595)

    To the moron who mod'ed this off topic: rot in hell you nazi prick.

  • by lgw (121541) on Tuesday March 04, 2014 @06:19PM (#46402733) Journal

    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)

    by Rob Y. (110975) on Tuesday March 04, 2014 @06:42PM (#46402969)

    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.

  • by jbn-o (555068) <mail@digitalcitizen.info> on Tuesday March 04, 2014 @06: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 [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.

"It's what you learn after you know it all that counts." -- John Wooden

Working...