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."
Everything I know of uses OpenSSL.
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 saw the patch first thing, then the warning telling me it wasn't trusted.
"If any question why we died, Tell them because our fathers lied."
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.
...at least since C was initially created (and perhaps even before that).
When do We accept that this is a failure intrinsic to the programming languages themselves and move on to correct it?
http://en.wikipedia.org/wiki/B...
Na-na-na-na-na.
This is C code, the only major language that doesn't know how big its arrays are. After 30 years of buffer overflow bugs, you'd thing we'd have something better now for low-level programming. The higher level stuff, where you can use garbage collection, is in good shape, with Java, C#, Python, etc. resistant to buffer overflow problems. C and C++, though, are still broken. C++ tries to paper over the problem with templates, but the mold (raw pointers) keeps seeping through the wallpaper.
I've tried. Here's my paper on a stricter version of C that's object-compatible with existing C code. It's techncally possible to fix this problem. The political problems are huge.
Well, this is Slashdot, so most stories are dupes anyway...
Should have used LibreSSL.
Yeah but since we're now thinking about this GnuTLS bug, I'm sure "telepathy" will start making calls to unknown servers.
I'll...I'll show myself out.
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?
FileZilla uses GnuTLS because the maintainer decided OpenSSL had an API that was too unwieldy.
The road to tyranny has always been paved with claims of necessity.
Note: Patch for FileZilla is already available. Update to 3.8.1 which uses GnuTLS 3.2.15.
The road to tyranny has always been paved with claims of necessity.
Shut up. ***I*** am APK.
APK
"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?
First of all, none of this has anything to do with "Linux". These are all user-land libraries and tools you're referring to. They are all available for Linux, BSD and Windows alike; including OpenSSL and GnuTLS.
Secondly, "top dog" has nothing to do with any of this either. Software such as OpenSSL and GnuTLS needs to be secure. That means that there should be no exploits. The amount of people "attacking" it is irrelevant given those constraints. Whether 1 researcher is looking for bugs or 10.000 criminals are trying to exploit it is irrelevant. None of them should be able to find anything useful.
Lastly, Windows as much as any other proprietary solution is completely irrelevant to this discussion to anyone with a sensible opinion on the topic. That's not because proprietary software is worse than free software, it's because proprietary software can never offer the kinds of security guarantees that free software can by mere virtue of their insistence on secrecy. What that means is, even if there is a proprietary replacement of OpenSSL for which no exploit is published in 10 years, you could never trust that the NSA, the Russians, the Chinese or the Iranians don't have a way in. You can't even trust that they haven't forced the company to add in back-doors and keep them secret. Essentially, proprietary software loses by default and free software is the only useful thing we have left, even if it sometimes fails at keeping its promises.
``OK, so ten out of ten for style, but minus several million for good thinking, yeah?''
C is that way because it had to interface to HARDWARE that doesn't know anything about size limitations.
That's what programming languages are for - to allow better abstractions than the hardware provides. That's what higher level languages are for. At the assembly code level, few assemblers know about array size, but C is not an assembly language. C knows about loops, and scope, which the hardware does not. This allows optimization of checks, which can often be hoisted out of a loop. (For non-compiler people, "hoisting" means moving a computation upwards in code, so that it's done earlier, preferably once per loop instead of once per iteration. Most optimizing compilers do some hoisting.)
And EVERY language you use has to interface at some point where "size" limitations are unknown.
To what? Even when you go to an I/O device, you're usually telling a DMA controller what the size of the buffer is.
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).
The VAX had integer overflow checking, which wasn't used much. I once rebuilt the UNIX command line tools on a VAX with the entry masks for functions set to raise a hardware exception on overflow. About half of the tools broke. The VAX machines were heavily microcoded, with explicitly sequential semantics within instructions. As a result, some of the fancier instructions were unreasonably slow. DEC had a terrible problem making VAX machines go faster. Then they went in the other direction with the Alpha, which was a very basic RISC machine. That went fast, but never caught on. All of this is irrelevant to modern computing.