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."
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
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?!
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.
Do you even lift?
These aren't the 'roids you're looking for.
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.
"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.
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.
I'd even go far as to say the problem creeps into larger issues. All the libraries you require are based in C/C++. QT, etc. These code bases are completely massive and even if you run some small "shows a box on screen" app you are calling 3000 lines of possibly broken an insecure code. The solution is move the core libraries away from C to C#, Java, or some other viable candidate that prevents software from "doing bad things". Essentially what the open source community has been saying is "trust us", but who exactly do you trust to carry your wallet? I only trust myself... How about you? Community developed software is great provided it is implemented on a framework that is invulnerable to input errors. I rather have my app crash than get hacked.
Guess what language the Java VM's or CLR VM are written... C and C++, sometimes assembly.
So what you are saying is we should not be codeing with libraries that are written in C or C++ instead we should be coding with VMs that are written in C and C++. And how exactly is that any better?
As for trusting these VM to not let code do bad things you mean like we should trust the VMs who's security was bad enough Homeland security issued an warning to dissable or remove it?
---Saying gnome 3 is better than windows 8 not so much a compliment as it is damning with light praise.
Well, this is Slashdot, so most stories are dupes anyway...
Should have used LibreSSL.
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).
Since I'm not using any of those to make calls to unknown servers, I'm not seeing a problem there.
It's not just that. How do you know you're not making a call to a compromosed server?
Or... if you're using C++, use a Standard Library container? They all keep track of their sizes, and can perform runtime bounds checks (by using say, at() rather than the bracket operator). Or Write your own class with an array member and an accessor that does bounds checking. It's not difficult to do. At all. And templates aren't meant for addressing buffer overflow problems, or as a replacement for raw pointer (use STL containers). Or garbage collection (use RAII). I get the feeling you aren't too familiar with C++?
"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.
How can I believe you when you tell me what I don't want to hear?
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.
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.
How is that a problem? Pass the size in a separate variable. Put the array in a struct and add a member for the size. Or add a function to your struct that returns the size. Whatever. The possibilities are there. If you don't use them because programming in C is less cushy than in other languages, the fault is entirely yours. There is nothing in C preventing you from writing proper code. You just have to do it, with the understanding that it will be more work. But it's hardly impossible.
If a train station is a place where a train stops, what's a workstation?
It's a problem because it requires programmers to concern themselves with low-level tedious details that the compiler could handle for them
So basically your statement can be reduced to is "If you're lazy and stupid, don't use C". I'm fine with that. But I'd like to add that if you're lazy and stupid, don't program at all, become a manager.
If a train station is a place where a train stops, what's a workstation?