Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

GnuTLS Flaw Leaves Many Linux Users Open To Attacks

Soulskill posted about 6 months ago | from the with-many-eyes-all-maintainers-are-grumpy dept.

Encryption 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."

Sorry! There are no comments related to the filter you selected.

Deja Vu? (0)

Anonymous Coward | about 6 months ago | (#47158273)

Didn't we already have something like this just weeks ago? The NSA is at work I assume.

Re:Deja Vu? (2)

by (1706743) (1706744) | about 6 months ago | (#47159019)

Well, this is Slashdot, so most stories are dupes anyway...

Who uses GnuTLS? (1)

Anonymous Coward | about 6 months ago | (#47158283)

Everything I know of uses OpenSSL.

Re:Who uses GnuTLS? (4, Informative)

Anonymous Coward | about 6 months ago | (#47158627)

"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.

still not seeing a problem (0)

Anonymous Coward | about 6 months ago | (#47158783)

Since I'm not using any of those to make calls to unknown servers, I'm not seeing a problem there.

Re:still not seeing a problem (1)

by (1706743) (1706744) | about 6 months ago | (#47159045)

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.

Re:still not seeing a problem (2)

kthreadd (1558445) | about 6 months ago | (#47159503)

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?

Re:Who uses GnuTLS? (0)

Anonymous Coward | about 6 months ago | (#47159021)

It is also already fixed. All the Linux distros worth something had the fix out very, very fast.

And this one doesn't cause lasting damage like heartbleed did. Patch it, and you're done.

The problem is the usual crap: embedded devices that never get updated, and shit commercial crap that insists on shipping with bundled libraries or statically linked.

Re:Who uses GnuTLS? (1)

OdinOdin_ (266277) | about 6 months ago | (#47160367)

But no major server software that another party can connect remotely to exploit.

Re:Who uses GnuTLS? (1)

Boltronics (180064) | about 6 months ago | (#47161785)


$ apt-cache rdepends libgnutls26 | tail -n +3 | wc -l
497

Oh crap...

Re:Who uses GnuTLS? (1)

_Ludwig (86077) | about 6 months ago | (#47162361)

Don't know about the others, but mutt has an option to compile with OpenSSL instead.

Re:Who uses GnuTLS? (1)

r1348 (2567295) | about 6 months ago | (#47158663)

If that makes you feel safe...

Re:Who uses GnuTLS? FileZilla (1)

Bacon Bits (926911) | about 6 months ago | (#47159575)

FileZilla uses GnuTLS because the maintainer decided OpenSSL had an API that was too unwieldy.

"malicious server" (3, Informative)

bill_mcgonigle (4333) | about 6 months ago | (#47158287)

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.

Re:"malicious server" (0)

Anonymous Coward | about 6 months ago | (#47158413)

wget uses OpenSSL on RHEL 6

Re:"malicious server" (4, Insightful)

kthreadd (1558445) | about 6 months ago | (#47159519)

Wget can be built for either OpenSSL or GnuTLS.

Re:"malicious server" (0)

Anonymous Coward | about 6 months ago | (#47158515)

Have you even read the analysis ?

$ echo `xbps-query -RX gnutls | cut -d - -f1`
cups empathy glib filezilla gtk2 cups libvlc libvirt qemu rsyslog bitlbee telepathy xbmc weechat vino xen xombrero ...

Re:"malicious server" (1)

bill_mcgonigle (4333) | about 6 months ago | (#47158727)

Have you even read the analysis ?

Did you notice that dependency tree only applies to voidlinux? Looking quickly, a few distros that were building wget against GNUTLS (wget is a GNU product), e.g. arch, are now building it against openssl, which is a step in the right direction (probably, maybe, ifs/ands/buts/save-us-libressl).

Re:"malicious server" (1)

Mr. Gus (58458) | about 6 months ago | (#47158987)

Exim uses gnutls on debian (and ubuntu, and probably other derivates).

Re:"malicious server" (0)

Anonymous Coward | about 6 months ago | (#47159599)

there's not much popular software that uses GNUTLS, but wget is one of them.

Not mine, it uses the high-quality openssl library :)

ldd /usr/bin/wget
                linux-gate.so.1 => (0xb76ec000)
                libssl.so.10 => /usr/lib/libssl.so.10 (0xb767d000)
                libcrypto.so.10 => /usr/lib/libcrypto.so.10 (0xb74b7000)
                libdl.so.2 => /lib/libdl.so.2 (0xb74b2000)
                librt.so.1 => /lib/librt.so.1 (0xb74a9000)
                libc.so.6 => /lib/libc.so.6 (0xb7311000)
                libgssapi_krb5.so.2 => /lib/libgssapi_krb5.so.2 (0xb72d1000)
                libkrb5.so.3 => /lib/libkrb5.so.3 (0xb71f4000)
                libcom_err.so.2 => /lib/libcom_err.so.2 (0xb71ef000)
                libk5crypto.so.3 => /lib/libk5crypto.so.3 (0xb71c4000)
                libresolv.so.2 => /lib/libresolv.so.2 (0xb71aa000)
                libz.so.1 => /lib/libz.so.1 (0xb7195000) /lib/ld-linux.so.2 (0xb76ed000)
                libpthread.so.0 => /lib/libpthread.so.0 (0xb717a000)
                libkrb5support.so.0 => /lib/libkrb5support.so.0 (0xb716e000)
                libkeyutils.so.1 => /lib/libkeyutils.so.1 (0xb716a000)
                libselinux.so.1 => /lib/libselinux.so.1 (0xb714b000)

Re:"malicious server" (1)

Carnildo (712617) | about 6 months ago | (#47159723)

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.

wget can be built against OpenSSL, and curl can be used with GnuTLS.

Laugh (1)

koan (80826) | about 6 months ago | (#47158301)

I saw the patch first thing, then the warning telling me it wasn't trusted.

Basic programming principles what? (5, Insightful)

maugle (1369813) | about 6 months ago | (#47158333)

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?!

Re:Basic programming principles what? (1)

Arakageeta (671142) | about 6 months ago | (#47158435)

It seems like taint tracking and sanitation should be pervasive and explicit. This can be partially enforced by type enforcement, no?

Re:Basic programming principles what? (1)

mean pun (717227) | about 6 months ago | (#47158831)

It seems like taint tracking and sanitation should be pervasive and explicit. This can be partially enforced by type enforcement, no?

This is possible in almost any modern language, although in some languages the code will be so horrible you can wonder if the cure isn't worse than the disease. For example, in C you could wrap tainted data in a struct that is only touched by a few select sanitisation functions. (You would still have to make sure no lazy or malicious code pokes around in the struct, or casts away this protection, but you could write a tool to check that.) Similar for languages like Python, although again it is easy to get around the isolation, so discipline and checking is still required. Languages like Java (or Swift :-)) are strict enough that you can almost completely enforce this isolation rather than rely on disciplined programming (I say almost because you cannot block access to I/O functions, so in principle you could still ignore the isolation, and directly access the tainted data). In C++ you can make the isolating `wrapper' almost transparent, but all the C trickery is still available.

I think it is fair to say that an important reason that these techniques are not used is cultural. Building a watertight taint wrapper in C (the most common language for this kind of code) is tricky and boring, and there is a lot of Real-Programmers-don't-Need-Handholding mentality among C programmers.

Re:Basic programming principles what? (4, Insightful)

QuietLagoon (813062) | about 6 months ago | (#47158453)

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:Basic programming principles what? (0, Insightful)

Anonymous Coward | about 6 months ago | (#47158581)

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:Basic programming principles what? (0)

Anonymous Coward | about 6 months ago | (#47158629)

Except, that is standard for OSS. For every one developer you would call a programmer

Ugh. This old argument again. I like how you totally overlook that most OSS developers are paid programmers. Closed source software experiences these exact same problems often enough; they just don't tell you about it in order to not tarnish their reputation.

there are a dozen copy-pasta

Oh. You come from 4chan. That explains a few things. Welp, didn't bother reading the rest of your post. Please go back from whence you came; trolling isn't much appreciated around these parts of the internet.

Re:Basic programming principles what? (1)

Anonymous Coward | about 6 months ago | (#47158679)

As someone who works on closed source software, let me tell you there is all sorts of bullshit that goes on with ignoring things until there is a financial advantage not to. Also anything with the word Enterprise or Cluster is usually a hackjob.

Re:Basic programming principles what? (1, Offtopic)

rsclient (112577) | about 6 months ago | (#47160327)

Actually, most of the comments I've seen about the OpenSSL code are immature, and show a lack of appreciation for the changes in the industry.

Like, remember that if-isupper-then-tolower code? Well, back in the day, tolower on most platforms would just bit-bang in a '1' bit. That will convert A to a, but also converts at-sign to back-tick. In "modern" toolchains, this doesn't happen any more; tolower is expected to handle all chars, and work correctly.

But -- as a developer, can you prove that every system that you're running on has a proper implementation of tolower? It's easy for me; I only work with one version of Visual Studio, and I can quickly prove that tolower work.

I've done code that works on multiple platforms. It used to be really, really gnarly: everything platform was always just a little bit different. And you get code that looks just like what I've seen in the snarky comments.

Re:Basic programming principles what? (3, Informative)

Just Some Guy (3352) | about 6 months ago | (#47160821)

I've done code that works on multiple platforms. It used to be really, really gnarly: everything platform was always just a little bit different. And you get code that looks just like what I've seen in the snarky comments.

No, you don't. If you have a broken printf on a platform, you write code like:

#ifdef BROKEN_PRINTF
int GOOD_printf(...) {
/* Work around the breakage */
}
#else
#define GOOD_printf printf
#endif

GOOD_printf("Hello, world!\n");

so that you've encapsulated the damage to one place in your codebase. You don't sprinkle #ifdef BROKEN_PRINTF a thousand different places in 20 modules if you don't want to go insane trying to keep track of it.

The OpenSSL devs aren't getting grief for writing complex code. They're getting grief for writing unnecessarily complex code by an order of magnitude, and they've earned every bit of it.

Re:Basic programming principles what? (1)

Anonymous Coward | about 6 months ago | (#47158469)

It all comes down to money and time in the end. Input verification type errors like this are the most common bug in all software, but most of those don't involve exploits just screw up something you are doing. The weakness is really in the fact that C/C++ are extremely long in the tooth with the way that they handle bounds checking and really -- we have CPU cycles to burn across the board at this point. If this were implemented in Java, C#, or any other modern language it just would be simply impossible to have the problem. It's very hard to prevent errors that are caused by undefined responses -- the way to do so is to quit using languages that permit them. I rather have a program crash land than run an exploit.

Re:Basic programming principles what? (1)

gbjbaanb (229885) | about 6 months ago | (#47159095)

you're not up to date are you - about 20 years out of date TBH.

C++ has had bounds checking of arrays for decades, either through guard pages at both ends, or with decent containers.

sure, when working with C constructs, you're falling back to C, but even then you could enable memory guard pages in most compilers. Its just that these are generally only enabled in debug builds (as if you don't spot the bug when you're testing debug, you're not likely to find it in release builds either I guess).

Re:Basic programming principles what? (3, Insightful)

rahvin112 (446269) | about 6 months ago | (#47158553)

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? (1)

FatdogHaiku (978357) | about 6 months ago | (#47158715)

...but you can't design something idiot proof because idiots are incredibly ingenious.

And incomprehensibly lucky...

Re:Basic programming principles what? (2, Insightful)

Anonymous Coward | about 6 months ago | (#47160187)

not exactly lucky ... it's just there so damn many of them ....

Re:Basic programming principles what? (1)

Anonymous Coward | about 6 months ago | (#47159705)

The rule should be to always verify, regardless of where the data comes from. You can catch a lot of bugs by not being too presumptuous about complex data structures or formats you receive from "trusted" callers.

But I'm not advocating belt & suspenders programming. That's usually bad engineering. Bridge builders don't decide to just toss in a few more girders "just to be on the safe side". Writing algorithms that are robust and resilient without being redundant takes a very thoughtful approach.

Re:Basic programming principles what? (3, Interesting)

cant_get_a_good_nick (172131) | about 6 months ago | (#47160199)

I think there's a basic issue here, and that's of "what do I want to work on". This is a problem in any project - it's not limited to coding.

I'm sure GNUTLS is coded how many things are coded. Lets start with a framework, and hang dummy code on it. Say "hey we got here!" when we got a packet. Then you flesh that out, and do what you really should do when you get that. Hey, it works! Beers all around. Then later, you start thinking "hmm, how can this get abused" and you add checks.

But wait, before you think of how you can get broken, you're like "this code needs real functionality, let me work on this next". And the boundschecks never get coded.

I'm sure you've been on a project where you thought "i really should cross all the T's, dot all the I's here" then your boss says "it works good enough" and you never get around to making it bulletproof. Or you do the fun drywall project at home, and you already sanded with 150 grit, you just not bother with the 300 grit.. it's good enough.

OpenSource doesn't mean it's not written by people, with peoples' quirks and issues.

announcing goatsecret (4, Funny)

larry bagina (561269) | about 6 months ago | (#47158369)

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.

Re:announcing goatsecret (2, Insightful)

Anonymous Coward | about 6 months ago | (#47158913)

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:announcing goatsecret (1)

GameboyRMH (1153867) | about 6 months ago | (#47159229)

I have developed a program that cracks goatsecret output: goatsextract. It is able to automatically extract the data from a frenchman's gaping asshole, without the user ever viewing the goatsecret image. Requires imagemagick, tesseract and leptonica.

Re:announcing goatsecret (0)

Anonymous Coward | about 6 months ago | (#47159727)

No hacker/cracker/big business/three-letter-agency is that desperate.

Not even evil aliens: "Oh God, Sir, they are still naked!" [youtu.be]

~45yrs of buffer overflows... (1)

devloop (983641) | about 6 months ago | (#47158445)


...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... [wikipedia.org]

Re:~45yrs of buffer overflows... (1)

Narcocide (102829) | about 6 months ago | (#47158493)

As soon as Ruby can walk the walk that they so brazenly talk while maintaining an acceptable performance level. People who *don't* design languages for a living still have to care about how the execution times for simple tasks affects their clients' operating costs. A true carpenter doesn't blame his tools for his own mistakes.

~45yrs of buffer overflows... (0)

Anonymous Coward | about 6 months ago | (#47158519)

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.

Re:~45yrs of buffer overflows... (1)

mindmaster064 (690036) | about 6 months ago | (#47158535)

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.

Re:~45yrs of buffer overflows... (2)

lister king of smeg (2481612) | about 6 months ago | (#47158907)

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?

Re:~45yrs of buffer overflows... (0)

Anonymous Coward | about 6 months ago | (#47161077)

To circumvent the JVM you simply compile the java source to machine code.

Re:~45yrs of buffer overflows... (1)

mindmaster064 (690036) | about 6 months ago | (#47161943)

Yes, but it's easier to worry about one library (the VM) than 5000. Also the need for "compiling" is caused by the limitation that your OS cannot directly digest the bytecode. If it could there is nearly no need for a C++ glue layer other than a very minimal one that can easily be secured. If it can read that code then the C++ dependency goes away outside of the small bit riding right on the hardware. Put C where it belongs -- touching the hardware -- move the standard libraries into the virtual sandbox. No more problems.

Re:~45yrs of buffer overflows... (3, Insightful)

ledow (319597) | about 6 months ago | (#47158549)

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:~45yrs of buffer overflows... (3, Insightful)

Animats (122034) | about 6 months ago | (#47158777)

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.

wrong. (2, Informative)

Anonymous Coward | about 6 months ago | (#47159203)

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).

Indeed, wrong (1)

Animats (122034) | about 6 months ago | (#47161991)

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.

Re:~45yrs of buffer overflows... (0)

Anonymous Coward | about 6 months ago | (#47158813)

If the problem is "buffer overflows" then a solution is to write a high performance, totally safe library designed to buffer data in C++ and cover every common high performance case and need.

I'm currently writing some C++ libraries, and I can say that there's some hurdles to getting clean, useful code written in C++. I'd kind of like to be interoperable with Boost, or even included in Boost one day - and doing that would require months or a year of clean up, help from maintainers, testing etc. C++ just barely makes it possible to expose abstractions cleanly, flexibly and interoperably. But it's possible.

Re:~45yrs of buffer overflows... (1)

Anonymous Coward | about 6 months ago | (#47158985)

Managed languages have a few problems.

First of all, they're slow due to JIT compiling. "Wait, what?" I hear you ask. Isn't JITting supposed to be faster? That's what we've all been told, right? No. JITting is faster than interpretation, including bytecode interpretation. JITting is not faster than raw machine code. Period. The fact that it has to be JITted is overhead enough to make it slow when compared to something that needs no immediate compilation. Now, that's not to say it doesn't help in certain cases. Anything using reflection is definitely going to benefit from the flexibility afforded by the approach. But anyone who has worked with managed code knows that reflection is a performance killer of epic proportions and should be used sparingly.

Second of all, managed languages don't bootstrap. They have dependencies. At a minimum, they require some kind of runtime environment. That runtime environment has to be written in some language. It didn't just appear out of thin air. It has to boil down to machine code at some point. Sure, you could make an ASIC, but for this kind of situation those are called "processors with microcode support", and then you're making your own machine code that just happens to align with an emulator you previously wrote for another platform.

None of this is to say that most programming shouldn't be done in a managed environment. Just don't get the grand idea that everything should be managed code. Especially things like encryption.

Encryption should, ideally, be a system device. That way, the device endpoint can be mapped to either a hardware implementation or a software virtual implementation and can be remapped as needed. It would also allow for multiple parallel implementations to be in use in the same system, just like you might have multiple network devices of various types and specifications.

Re:~45yrs of buffer overflows... (1)

lgw (121541) | about 6 months ago | (#47159151)

The performance hit and need for the runtime is a big problem in many ways. Compiling to native code is the right path to jumping those hurdles. For C#, .NET Native [microsoft.com] is quite interesting. I can think of so many ways MS could ruin this, but the prospect of a stand-alone exe compiled from C# is exiting.

Re:~45yrs of buffer overflows... (1)

Anonymous Coward | about 6 months ago | (#47159157)

"system libraries can be written in any language you like"

Let me know when your language of choice can make a system call without using assembly...

Re:~45yrs of buffer overflows... (1)

Anonymous Coward | about 6 months ago | (#47158965)

I think it's a bit weak to blame the programming language on sloppy programming. Since when do we blame the tools for shoddy workmanship?

Re:~45yrs of buffer overflows... (0)

Anonymous Coward | about 6 months ago | (#47162529)

Well... yes. If Ryobi sold a circular saw with no protective guard and millions of their customers cut off their limbs, they'd get sued over it.

You'll never eradicte shoddy workmanship. You can, however attempt to minimize or contain its impact.

Windows never looked so good (1)

Anonymous Coward | about 6 months ago | (#47158461)

Na-na-na-na-na.

Re:Windows never looked so good (1)

Anonymous Coward | about 6 months ago | (#47158577)

Rest assured the Windows bugs are there. It's just that only malicious individuals and GO's know about them and they ain't saying shit because they use them[or sell them].

Re:Windows never looked so good (1)

Anonymous Coward | about 6 months ago | (#47158659)

Yup. Good thing that no open-source libraries are available for Windows, right? And, I mean, Microsoft is perfect. Not like they release thousands of bug fixes for each iteration of their operating systems.

Thank you for your infinite wisdom, AC.

Re:Windows never looked so good (0)

Anonymous Coward | about 6 months ago | (#47159823)

This has nothing to do with what the AC troll parent said:

I don't understand this, no software is perfect, no software is shipped without bugs, only crappy software remains the same years after it's released, so:

Why the fuck updates are considered wrong?. This is not the first time i see someone bitching about updates.
Why the fuck do you bitch about updates?, is not like Linux doesn't get updates, any OS without updates gets fucked pretty quickly.

C strikes out again (1, Flamebait)

Animats (122034) | about 6 months ago | (#47158551)

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. [animats.com] It's techncally possible to fix this problem. The political problems are huge.

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47158861)

Why C and not C++?

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47159061)

Pretty sure it's trivial to write a class that does keep track of it's buffer sizes if you want/need one. Also pretty sure there are lots of readily available classes that do this for you if you choose to use them.

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47159143)

There's a programming culture flaw that is more responsible for these bugs than any hazard in the language of choice.

Simplified:
Real programmers of the past wrote amazingly efficient programs in C that sometimes even use things like integer overflows as intentional features to improve performance.
Myth distorts and simplifies that truth to 'Real programmers use C'
Then many who hear the myth and seek to prove their status will program in C, but without understanding how much responsibility is on the programmer in such low-level languages.

So now you have a collection of programmers who know the habits of whatever language they first learned (Python, Java, Malbolge, etc.) and apply it to C with only as much tempering as needed to get a successful compile that works for their limited selection of test cases. From my glance at the actual bug, this is similar to heartbleed in that one end of a communication trusted inputs from the other end even about things that are easy to test for in C. (array length tests are well documented, even if there isn't a 'length' property to ask)

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47159155)

Not usually one to repeat my posts, but this thread needs this reply too:

I think it's a bit weak to blame the programming language on sloppy programming. Since when do we blame the tools for shoddy workmanship?

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47160659)

Ummm, we always blame shoddy tools because they are. But the tools are made by shoddy inventors, with shoddy short term design goals. We couldhave had tertiary computing base, but enough people were around to accept dog shit.
We are not all theoretical physicists, some of us have work to do.
I guess my point is, people will only work till 11:00 o'clock, But only if they show up late and need to catch up to the rest of the fuckin linux cube dwellers. But to really rub it in the windows maggots will use c++ because that book has more pictures.

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47162539)

Same reason we recall faulty or dangerous cars for the accidents drivers have in them.

Re:C strikes out again (1)

buttfuckinpimpnugget (662332) | about 6 months ago | (#47159161)

Or just use the openbsd tools and practices. strlcpy() and friends. Adding another layer won't make shitty brogrammers any better. People writing and using security software should have known better. But the code was so bad nobody wanted to look at it. Everyone failed, everyone. Including the OpenBSD project. On top of that, they purposely added their own memory allocation tools, thereby preventing the built in tools from finding the bugs. (exploit mitigation mitigation). There's no evidence but man, come on, this was done on purpose.

Re:C strikes out again (1)

Greyfox (87712) | about 6 months ago | (#47159183)

The programmers always know how big those arrays are. They're just lazy or bad in a variety of ways. It's easy enough to bound a read or copy to a specific size. They just never actually do. I've been on a couple of big C projects and a few smaller ones and the programmer always know what they're working with in a specific function. The problem is never that they don't know how big that specific thing is. The problem is they make no effort to validate the size, or that the pointer's not null, or that someone put good data in it. The number of ways programmers will find to be bad or lazy are countless, and I don't think you can make a language that will account for all of them while still being useful.

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47159539)

I think at least in my programs it's because I'm too lazy to do a NULL check in every single function that uses something.
At some point I want to be able to assume that something exists without having to check it every single time.

Re:C strikes out again (1)

Greyfox (87712) | about 6 months ago | (#47161109)

I should point out that the same programmers are usually the ones with tons of null pointer exceptions in their java logs that no one ever reads. You'd think someone would read the log every so often, say "Hmm. There are a lot of exceptions in here. Maybe I should fix a few of them since the stack trace points you right to the line where the exception occurred!" Nope! Not so much!

Re:C strikes out again (1)

techno-vampire (666512) | about 6 months ago | (#47160791)

I haven't done any programming in years, but when I did, I worked in C. On every project that I worked on, we were expected to use strncpy() instead of just strcpy() to make sure that we didn't copy more bytes than we had room for. AFAIK, not one of those projects ever had a buffer overflow issue. Why this isn't the standard now is beyond me.

Re:C strikes out again (1)

Anonymous Coward | about 6 months ago | (#47159333)

That "stricter version of C ... " is also slow.

Runtime checks are already possible... but are slow to use. And the runtime checks STILL have to be implemented by something that doesn't have runtime checks...

C is what it is. Good for implementing whatever you want. And that means it has to allow you to do things that shoot yourself in the foot.

C is used to implement programs for things from an 8 bit processor used for controllers (see PIC for an example - some only have 256 bytes of ram, and 2K of rom; Think all that forced runtime checks will fit?) to 64 bit supercomputers.

It is the portable assembler of the age.

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47159455)

BTW, you make the same mistake in the paper that happens a lot...

There is a difference between the size of a storage array, and the size of the USED storage.

Without that acknowledgment anytime you have an array change its size (in a structure for instance), you must also dynamically change the storage size allocated. And that leads to hundreds of allocations, deallocations and reallocations of data storage.

VERY inefficient.

VERY slow.

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47162547)

slow > insecure

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47159379)

Pfft... there is nothing in C/C++ that prevents doing boundary checks, the problem is attitudes where even if it won't make a dent in the overall performance it's still deemed "slow". That is, the whole identity of C/C++ revolves around the bad image where it isn't quite as fast as fortran and then if you use higher level fixings the people who are happy to waste clock cycles in Java/Python bash the code for being slow(er then it needs to be).

p.s. I've yet to hear of the fairy land where Java or Python could do anything sensible without going native C half the time.

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47159917)

You don't need a stricter version of C. There's nothing inherent about the C language that prevents automatic bounds checking. You can easily write a strictly conforming C implementation that can catch buffer overflows just as easily as Java. And there have always been implementations that did this, they just weren't widely used. For example, the Tiny C Compiler (TCC) has a bounds checking mode that can catch all overflows, both read and write, by even a single byte, including stack arrays.

Fortunately GCC and clang are starting to include some of this instrumentation as optional features. Also, Intel is debuting instructions to speed up these checks. These solutions aren't comprehensive, in part because they can require ABI changes, but they're a step in the right direction.

C is an amazing language. I write protocol parsers, and I couldn't think of an easier language in which to write simple and clear state machines. All of the safety aspects of C are implementation issues, and have nothing to do with the language. Of course, sometimes I do prefer more abstraction, but I tend to skip C++ entirely and jump to languages with GC, first class functions, tail recursion, and coroutines. My favorite language is Lua, which happens to be written in 100% ANSI C, has a beautiful and easy to read virtual machine, and blows the socks off of Python and other languages in terms of both speed and portability.

Re:C strikes out again (2)

GiganticLyingMouth (1691940) | about 6 months ago | (#47160109)

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++?

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47160595)

Typically, a language that does bounds checking on its arrays will compile an expression like 'x[n]' into at least three machine code instructions (compare, conditional jump, move), but ones that skip bounds checking can compile it to as little as one instruction (move). Crypto is CPU intensive and does a lot of 'x[n]'.

Re:C strikes out again (0)

Anonymous Coward | about 6 months ago | (#47160833)

Cryptographic algorithms tend to process blocks of data. The expensive parts involve all the operations on a single block. A smart compiler can in many cases hoist the bounds checking outside of the loop.

Anyhow, that's really beside the point. The very fact that smart compilers can easily optimize those loops also means that it's very easy for humans to spot bugs. None of the recent bugs in these libraries were in the core cryptographic code. They were all in network and state management code. Which means they could have theoretically just used a dumb compiler with [relatively] slow bounds checking instrumentation, and disabled that instrumentation for the core cryptographic code. Win-win.

Unfortunately, that option isn't yet available. But it's not far away.

Whoops (2)

Anonymous Coward | about 6 months ago | (#47159041)

Should have used LibreSSL.

What's the /. FUD "mantra" we all heard? (-1)

Anonymous Coward | about 6 months ago | (#47160049)

For YEARS now? "Windows != Secure, & Linux = Secure"?? B.S., & ANDROID does the rest on THAT note... along with OpenSSL & now THIS GnuTLS as well!

* :)

(Before ANY of your "fanboy apologists" give me any guff, realize your BULLSHIT IS FALLING APART AROUND YOUR EARS, nearly daily - since once you're the most used? You're the MOST attacked... period!)

APK

P.S.=> Worst part is, I actually *LIKE* Linux (though I prefer Windows due to better drivers & availability of them for more hardwares is all) - I just NEVER liked the b.s. "mantra of FUD" we all heard here for years is all, since I knew it would come apart IF Linux were ever the most used OS on any platform - smartphones did that for me, with ANDROID (& yes, it IS a Linux - running JAVA (dalvik) ontop of it, & we all KNOW how 'secure' that is (not))...

... apk

Re:What's the /. FUD "mantra" we all heard? (0)

Anonymous Coward | about 6 months ago | (#47160491)

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).

Re:What's the /. FUD "mantra" we all heard? (0)

Anonymous Coward | about 6 months ago | (#47160681)

Get on topic.

Re:What's the /. FUD "mantra" we all heard? (1)

Anonymous Coward | about 6 months ago | (#47160665)

Shut up. ***I*** am APK.

APK

Grow up, & get on topic troll (-1)

Anonymous Coward | about 6 months ago | (#47160701)

See subject-line: Don't you have anything better to do, than being a useless off-topic troll?

APK

P.S.=> I really feel sorry for you in a way - however: I imagine you're some adolescent "getting his jollies" attempting (& failling) @ impersonating me - you need a life, or @ least something CONSTRUCTIVE to occupy yourself with, instead of being an immature fool (seriously)... apk

Re:What's the /. FUD "mantra" we all heard? (3, Funny)

pushing-robot (1037830) | about 6 months ago | (#47160943)

"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.

Security by Obscurity only... apk (-1)

Anonymous Coward | about 6 months ago | (#47161031)

When you're not used as much as "the top dog" it makes NO sense for malware makers to go after you when a LARGER target mass is out there (on PC's, that's Windows, where the "non-techie" EASIER VICTIMS are).

Still -. What proves it yet again? ANDROID, a Linux, is now the "top dog" on smartphones & it's get TORN UP, nearly daily, by the same general things Windows was (not just trojans suckering users but things like OpenSSL having holes, now this GnuTLS, etc.).

Anybody that's been around this field long enough the past 30 yrs. now would've told you the same & been rcorrect, in the LONG RUN... & here we are.

(Like your "humor" by the by...)

APK

P.S.=> Personally, I hope Linux KEEPS GROWING the way it has (sure has come a LONG ways since 1994 in Slackware 1.02 when I first tried it, that's for sure & giving credit where it's due), but like I told the former Microsoft head of the Windows Performance Division I met here (albeit by email) that ONE day? It is BOUND to catch up to Windows... so, what makes ME happy about that? 2 things = I am NOT "bound" to any particular platform since I code, & secondly, Linux getting BETTER forces MS to keep improving things on THEIR end (competition = GOOD that way)...

... apk

Re:Security by Obscurity only... apk (1)

lhunath (1280798) | about 6 months ago | (#47161865)

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.

No? Look @ the article title... apk (0)

Anonymous Coward | about 6 months ago | (#47161977)

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

Re:No? Look @ the article title... apk (0)

Anonymous Coward | about 6 months ago | (#47162487)

APK, you are my favorite character. I hope the writers don't kill you off in the season finale.

Love, Chris
Age 9.

Re:No? Look @ the article title... apk (0)

Anonymous Coward | about 6 months ago | (#47162497)

P.S. Did you know that APK is the type of linux file that all android applications are made in the image of? The world is fool of such wonderful things, isn't it?

You're biggest fan,
Chris

Re:Security by Obscurity only... apk (0)

Anonymous Coward | about 6 months ago | (#47161909)

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.

How's this "Windows' Ownage"? (0)

Anonymous Coward | about 6 months ago | (#47161999)

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

Basic Question (0)

Anonymous Coward | about 6 months ago | (#47161753)

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

 

Flamebait headline (0)

Anonymous Coward | about 6 months ago | (#47162585)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?