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."
Didn't we already have something like this just weeks ago? The NSA is at work I assume.
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.
Just write a new language - using C of course, like every single other piece of interface/middleware/library code.
Call me when you find an alternative which actually gets the job done.
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.
Since I'm not using any of those to make calls to unknown servers, I'm not seeing a problem there.
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).
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.
Who are you and what have you done with the real APK? There's no block quotes, no bold, no random links, no ranting about whoever looked at you funny yesterday, and only one ascii art arrow.
It's like reading a post written by a normal person. Ditch blockcaps and people might even stop harassing you (capslock = cruise control for annoying).
Shut up. ***I*** am APK.
APK
Get on topic.
"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?
Network-orientied programs with "buffer overrun" problems have been an issue for at least a DECADE, so at this point I really feel we all need to ask a basic question: What incompetent FLAMING IDIOT writes ANY program that allows data to EVER overrun an allocated buffer????
We need an internet campaign to "name and shame" any moron who EVER writes ANY code with such a mind-blowingly idiotic error that any beginning coder should no not to commit. This stuff is so insanely basic that it's right up there with using an uninitialized pointer, and goes to programming fundamentals. At this point, if you are dumb enough to write code that allows data to overrun a buffer I have to wonder if you know other basic things like: hexadecimal numbers, the difference between signed and unsigned ints, and how to compile a program without a fancy IDE.
Any time an opern-source app is found to have such a flaw, it needs to be forked and a new branch needs to be taken over by MINIMALLY COMPETENT programmers (ALL the work of the coders who released the "bad version" should be considered suspect for at least a decade). Any closed-source vendor releasing code with such a basic and easily avoided error should similarly be presumed to have no competence and no quality control for a decade. Buffer overruns are simply not an excusable error; they're not some mid-blowingly complex problem that could crop-up in some narrow corner-case in an app which any developer can understandably miss. There are plenty of bugs a programmer can be forgiven for making (absent an open-ended product release schedule that allows time to produce perfection) and which we all expect to see updates and patches released to fix..... but buffer overruns are NOT in this category! I've not personally been harmed by these recent bugs, but this angers me (and hopefully many other long-time coders) because I hate stupidity and laziness, and for such a simple and basic error to continue to afflict so many programs after so many years of awareness there is simply no other explanation than: STUPID, LAZY and INCOMPETENT
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?''
Not many people run servers on Androids to be impacted by Heartbleed.
This is a far worse vulnerability, even thou limited by the little usage this package has and the fact the client system is not actually compromised, just the user's account.
Windows => Severe vulnerability = system ownage
GNU Linux => Severe vulnerability = user account ownage
Yeah, Linux still has a little while to go.
Per my subject-line: THIS IS IT -> GnuTLS Flaw Leaves Many Linux Users Open To Attacks - I see "Linux" in it, now "eat your words"...
APK
P.S.=> Now THAT? Well... lmao, you KNOW that NOW I've just GOTTA say it, don't you? Ah, but of COURSE you do:
THIS? This was just "too, Too, TOO EASY - just '2ez'"... apk
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.
Does Windows use GnuTLS?? Hell no... not even a "nice try" on YOUR part there...
APK
P.S.=> All I know is, all those YEARS of "FUD" b.s. propoganda of "Linux = Secure' shows its TRUE COLORS on Android - where, for once, Linux has a TOP SPOT in most used... AND MOST ABUSED because of that!
... apk
Thanks Slushpot for the flamebait article GnuTLS Flaw Leaves Many Linux Users Open To Attacks
Except that its not true. There are no actual services running on the Linux operating system that use GnuTLS. There are some open source tools that use this (wget is most common), but you can compile wget for windows too. But that wouldn't be as sensational.
...you need a life...
One can only assume that the irony of this statement is lost on you.
Before someone starts complaining that crypto libs are written in C, you better remember of the following HARD requirements on crypto libraries for real work, which directly translates into requirements on the language it will be implemented in:
1. Generate machine code resilient against power and timing analysis;
2. Generate machine code that is actually capable of secure memory handling and secure object lifetime control.
You cannot do it in standard java, for example. It is downright impossible, because the language simply does not support it. Too bad it is quite hard to do it right in C, but it is *possible*.
There is no reason why languages cannot be extended to be actually useable for secure code, but that can be quite hard to do: bytecode-based languages will likely need changes to their VM model, for example.
It appears, based on our firewall logs that all Windows 8.1 computers are being attacked by one of Microsoft's edge servers WHEN the computer is accessing the BING search engine. Server IP is always the same 204.79.197.200, and ONLY Windows 8.1, not Windows 7.