GnuTLS Flaw Leaves Many Linux Users Open To Attacks 127
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."
Basic programming principles what? (Score:5, Insightful)
Re:Basic programming principles what? (Score:5, Insightful)
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:~45yrs of buffer overflows... (Score:4, Insightful)
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:Basic programming principles what? (Score:4, Insightful)
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? (Score:0, Insightful)
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".
Except, that is standard for OSS. For every one developer you would call a programmer, there are a dozen copy-pasta adepts who just mash copied code together and hammer the edges until it works in their 3 test cases.
For all the debate about Linus's aggressive responses to some submitters, that is the closest to quality assurance that OSS typically can rely on. Closed-source for-profit software is typically backed by a company that is willing to (but not always competent at) fire bad programmers whose contributions end up adding more work for others than solving problems.
Re:~45yrs of buffer overflows... (Score:4, Insightful)
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:announcing goatsecret (Score:2, Insightful)
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.
Re:"malicious server" (Score:5, Insightful)
Wget can be built for either OpenSSL or GnuTLS.
Re:Basic programming principles what? (Score:2, Insightful)
not exactly lucky ... it's just there so damn many of them ....
Re:Who uses GnuTLS? (Score:2, Insightful)
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.