Slashdot Mirror
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."
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?!
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.
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.
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.
... neither is the intended recipient of the data.
That's the only flaw with your scheme I can think of.
Wget can be built for either OpenSSL or GnuTLS.
The are basically no embedded devices with GnuTLS, it is GPLv3 licensed and there are much more free packages available (OpenSSL, ...) It is also known for being insecure.