GnuTLS Flaw Leaves Many Linux Users Open To Attacks

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

Comments

"malicious server"

[bill_mcgonigle]

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:"malicious server"

[kthreadd]

Wget can be built for either OpenSSL or GnuTLS.

Basic programming principles what?

[maugle]

I don't understand what the programmers of all these crypto libraries were thinking here. Even for the most basic and unimportant program, the rule is "if the data comes from outside, verify!" This is vastly more important when cryptography is involved, so why is it that all these crypto libraries seem to blindly trust whatever the Internet is sending them?!

Re:Basic programming principles what?

[QuietLagoon]

I don't understand what the programmers of all these crypto libraries were thinking here. Even for the most basic and unimportant program, the rule is "if the data comes from outside, verify!" This is vastly more important when cryptography is involved, so why is it that all these crypto libraries seem to blindly trust whatever the Internet is sending them?!

From what I read of the OpenSSL source code, it would be an insult to programmers everywhere to call the people who barfed up the OpenSSL code "programmers".

Re:Basic programming principles what?

[rahvin112]

The actual rule is you always verify data, regardless of source. You might trust internal data to not be intentionally malicious but you can't design something idiot proof because idiots are incredibly ingenious.

Re:Basic programming principles what?

[cant_get_a_good_nick]

I think there's a basic issue here, and that's of "what do I want to work on". This is a problem in any project - it's not limited to coding.

I'm sure GNUTLS is coded how many things are coded. Lets start with a framework, and hang dummy code on it. Say "hey we got here!" when we got a packet. Then you flesh that out, and do what you really should do when you get that. Hey, it works! Beers all around. Then later, you start thinking "hmm, how can this get abused" and you add checks.

But wait, before you think of how you can get broken, you're like "this code needs real functionality, let me work on this next". And the boundschecks never get coded.

I'm sure you've been on a project where you thought "i really should cross all the T's, dot all the I's here" then your boss says "it works good enough" and you never get around to making it bulletproof. Or you do the fun drywall project at home, and you already sanded with 150 grit, you just not bother with the 300 grit.. it's good enough.

OpenSource doesn't mean it's not written by people, with peoples' quirks and issues.

Re:Basic programming principles what?

[Just Some Guy]

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 */
}
#else
#define GOOD_printf printf
#endif

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.

announcing goatsecret

[larry bagina]

There have been too many problems with existing crypto code so I've developed something better: goatsecret. Instead of relying on math, it relies on a frenchman's gaping asshole. Basically, the software breaks your message/file/whatever into small chunks and superimposes the data in the goatsecret image. Sure, it's not encrypted, but who is going to stare into the void just to get your data? No hacker/cracker/big business/three-letter-agency is that desperate.

Re:~45yrs of buffer overflows...

[ledow]

The alternative of runtime-performance hits, and allowing arrays to grow to unreasonable - and uncontrollable - sizes without inserting checks similar to those that combat buffer overflows just seems to be something that nobody wants.

Fact is, moan all you like, system libraries can be written in any language you like, and interface with C code and C-style functions quite easily. There's nothing stopping - as Windows is moving towards - system libraries being written in a managed language and interfacing with old-style C API's.

But nobody's doing that. Not because buffer overflow in C isn't a problem, not because they naively think their code is bulletproof. But simply because of reasons of performance, memory use and knock-on library sizes and dependencies.

Nobody is stopping yourself, or anyone else, from rewriting something as performance critical as GnuTLS in any language you like. But nobody has. And if they have, nobody that develops code that requires GnuTLS uses it.

For kernels and drivers, I'd fight the corner of "It has to be C, or a similar, dangerous, low-level language". Once you get to the application layer of things like OpenSSL, GnuTLS, or pretty much any library, there's no excuse. Nobody's writing them, and if they are they are losing out to the C-based libraries. And not BECAUSE they are written in C and we all have this nostalgia for crappy C code, not BECAUSE these things must be written in C to work properly, not BECAUSE the API is C-based and not language interfaces with it - but obviously because of other reasons.

What those exact reasons are, I'll leave others to discuss. But I greatly suspect it's to do with the huge size and impact of such managed languages.

Re:Who uses GnuTLS?

[Anonymous Coward]

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

Re:~45yrs of buffer overflows...

[Animats]

No, it's a backwards compatibility issue. There's all that C code out there, sort of working. It's not an overhead issue. Most subscript checks in inner loops can be hoisted to the top of the loop and optimized out. For FOR loops, this is almost a no-brainer inside a compiler. The Go compiler, which checks subscripts, does that.

There are three big memory issues in C: "How big is it","Who deletes it", and "Who locks it?". The language helps with none of those. "How big is it" problems lead to buffer overflows and security holes. "Who deletes it" leads to memory leaks, and occasionally use after deletion. "Who locks it" leads to race conditions. Of these problems, "How big is it" cause the most security trouble.

C is especially bad because the language doesn't even have a way to talk about the size of an array. When you pass an array to a function, all size info is lost. This sucks.

C is this way because the compiler had to be crammed in a machine with an address space of 128KB, the PDP-11. We have more memory now. I first wrote C in 1978. We should be past this mess by now.

Re:What's the /. FUD "mantra" we all heard?

[pushing-robot]

"Windows != Secure, & Linux = Secure"??

It was true for a long time, but then someone trying to be helpful changed it to "Linux == Secure" and it was no longer.