Follow Slashdot stories on Twitter


Forgot your password?
Encryption Software Bug Security Linux

GnuTLS Flaw Leaves Many Linux Users Open To Attacks 127

A new flaw has been discovered in the GnuTLS cryptographic library that ships with several popular Linux distributions and hundreds of software implementations. According to the bug report, "A malicious server could use this flaw to send an excessively long session id value and trigger a buffer overflow in a connecting TLS/SSL client using GnuTLS, causing it to crash or, possibly, execute arbitrary code." A patch is currently available, but it will take time for all of the software maintainers to implement it. A lengthy technical analysis is available. "There don't appear to be any obvious signs that an attack is under way, making it possible to exploit the vulnerability in surreptitious "drive-by" attacks. There are no reports that the vulnerability is actively being exploited in the wild."
This discussion has been archived. No new comments can be posted.

GnuTLS Flaw Leaves Many Linux Users Open To Attacks

Comments Filter:
  • "malicious server" (Score:4, Informative)

    by bill_mcgonigle ( 4333 ) * on Tuesday June 03, 2014 @02:41PM (#47158287) Homepage Journal

    malicious server

    Sorta important - there's not much popular software that uses GNUTLS, but wget is one of them. Since it's almost always used as a client, it's probably wise to use curl -O against unknown servers, until they get this straightened out.

  • Re:Who uses GnuTLS? (Score:4, Informative)

    by Anonymous Coward on Tuesday June 03, 2014 @03:17PM (#47158627)

    "apt-cache showpkg libgnutls26" says that mutt, claws-mail, empathy, emacs, telepathy, wine, and some qemu stuff uses it.

    So it is not completely unused.

  • wrong. (Score:2, Informative)

    by Anonymous Coward on Tuesday June 03, 2014 @04:14PM (#47159203)

    C is that way because it had to interface to HARDWARE that doesn't know anything about size limitations.

    And EVERY language you use has to interface at some point where "size" limitations are unknown.

    And if the hardware (ie, the CPU) has such instructions (like the VAX did) you then bump into the problem of lack of portability... And the CPU is then so constrained that it can't evolve either... (also a VAX problem - it had so many things bound to a 32 bit address that it couldn't go to 64 bits, and remain a VAX).

  • I've done code that works on multiple platforms. It used to be really, really gnarly: everything platform was always just a little bit different. And you get code that looks just like what I've seen in the snarky comments.

    No, you don't. If you have a broken printf on a platform, you write code like:

    #ifdef BROKEN_PRINTF
    int GOOD_printf(...) {
    /* Work around the breakage */
    #define GOOD_printf printf

    GOOD_printf("Hello, world!\n");

    so that you've encapsulated the damage to one place in your codebase. You don't sprinkle #ifdef BROKEN_PRINTF a thousand different places in 20 modules if you don't want to go insane trying to keep track of it.

    The OpenSSL devs aren't getting grief for writing complex code. They're getting grief for writing unnecessarily complex code by an order of magnitude, and they've earned every bit of it.

Testing can show the presense of bugs, but not their absence. -- Dijkstra