Beta

Slashdot: News for Nerds

×

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!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Bug In the GnuTLS Library Leaves Many OSs and Apps At Risk

Soulskill posted about 5 months ago | from the feeling-secure-is-the-biggest-bug dept.

Security 231

New submitter williamyf writes "According to this article at Ars Technica, '[A] bug in the GnuTLS library makes it trivial for attackers to bypass secure sockets layer (SSL) and Transport Layer Security (TLS) protections available on websites that depend on the open source package. Initial estimates included in Internet discussions such as this one indicate that more than 200 different operating systems or applications rely on GnuTLS to implement crucial SSL and TLS operations, but it wouldn't be surprising if the actual number is much higher. Web applications, e-mail programs, and other code that use the library are vulnerable to exploits that allow attackers monitoring connections to silently decode encrypted traffic passing between end users and servers.' The coding error may have been present since 2005."

cancel ×

231 comments

First (-1)

Anonymous Coward | about 5 months ago | (#46401749)

First, and yet another OSS-releated security risk :(

Re:First (3, Insightful)

lister king of smeg (2481612) | about 5 months ago | (#46402071)

First, and yet another OSS-releated security risk :(

At least they are rare enough that it is news worthy. As compared to Windows where new exploits hardly ever get any attention because they are so frilling common as to be passé.

"Error" is Plausable Deniability (5, Interesting)

Jeremiah Cornelius (137) | about 5 months ago | (#46402209)

Hot on the heels of Apple's SSL/TLS implementation "flaw" across all stacks, and the Snowden revelations of NSA infiltration for weakening crypto?

You don't have to be wearing Tin Foil, just to become a little suspicious...

Re:First (0)

Anonymous Coward | about 5 months ago | (#46402255)

...as to be passé.

I do not think that word means what you think it means.

That reminds me (0, Offtopic)

afidel (530433) | about 5 months ago | (#46401753)

The Ars side widget is broken, perhaps they don't want me to see the Ars articles until they have time to approve their copies here on slashdot...

Moderation (1, Offtopic)

mythosaz (572040) | about 5 months ago | (#46401763)

Posting to undo moderation.

Re:Moderation (0, Insightful)

Anonymous Coward | about 5 months ago | (#46402595)

To the moron who mod'ed this off topic: rot in hell you nazi prick.

Clearly this is Apple's fault (0, Offtopic)

Anonymous Coward | about 5 months ago | (#46401783)

No, I can't explain how, but it's pretty obvious.

AHAHAHAHAH (1, Insightful)

Anonymous Coward | about 5 months ago | (#46401795)

"Open Source Software is more secure because the code can be reviewed."

That's why this bug has existed since 2005. gg, guys. Thumbs up.

I'm Freetardicus!!! (0, Troll)

Anonymous Coward | about 5 months ago | (#46401855)

Downmod this Micro$hit shill!!! How dare he spread FUD about free software. It's perfect and bug-free because of the many eyes auditing the codes!

Re:AHAHAHAHAH (1)

Anonymous Coward | about 5 months ago | (#46402091)

Better late than never.

Re:AHAHAHAHAH (5, Interesting)

lister king of smeg (2481612) | about 5 months ago | (#46402137)

"Open Source Software is more secure because the code can be reviewed."

That's why this bug has existed since 2005. gg, guys. Thumbs up.

What do you mean? The many eyes found said bug that is why we are reading about it if thay had not it would still be sitting there undiscovered. Ever wonder how many bug go completely unnoticed in proprietary software because no one actually reads said code? Like for example a Windows bug affecting all 32 bit Windows OS's for 17 years: http://www.computerworld.com/s... [computerworld.com] .

Re:AHAHAHAHAH (0)

Anonymous Coward | about 5 months ago | (#46402221)

Do you know why bugs go undiscovered? It's not because of someone not staring at the code. It's poor testing of the binaries via fuzzing tools, etc. Most security bugs like this are found by binary analysis not reading souce code.

Re:AHAHAHAHAH (-1)

Anonymous Coward | about 5 months ago | (#46402307)

Except this bug
WAS discovered [openldap.org] back in 2008 and ignored.

Sorry, the OSS's mantra that it's more secure because it's peer reviewed is the emperor's new clothes.

Re:AHAHAHAHAH (5, Informative)

bonch (38532) | about 5 months ago | (#46402443)

The bug was found due to observed behavior, not due to a code review.

Re:AHAHAHAHAH (4, Insightful)

Rob Y. (110975) | about 5 months ago | (#46402969)

That may be, but once the behavior was observed, the observer didn't have to find the owner of the code to get it diagnosed. They may have, but the point is that anybody who found this behavior could've gone into the code and found out what caused the problem. Of course, if a black hat happened to be the one that found the bad behavior, they could've gone into the code to figure out how best to exploit it. So, the situation's not perfect, but still, it's probably a good thing that there were lots of eyes allowed to diagnose and fix the problem once it displayed itself.

Bug was NOT found due to being open source (2, Insightful)

Anonymous Coward | about 5 months ago | (#46402519)

The many eyes found said bug that is why we are reading about it if thay had not it would still be sitting there undiscovered.

This bug wasn't found from being open source. Those "many eyes" missed this bug for nearly a decade. Security testing tools uncovered incorrect validation behavior in the compiled library, just like they would with a closed source library. The only difference is that the public can see the incorrect code and correct it immediately; that is what you should be citing as an advantage of open source.

Re:AHAHAHAHAH (0)

Anonymous Coward | about 5 months ago | (#46402817)

There have been multiple decade+ year old Linux security vulnerabilities too. So your example is hardly a good one for why open source is better as the same problem exists here too. The truth is every OS with a long history will have decades old vulnerabilities, it is simply in the nature of coding that anything so complex can never be made perfect and if you have something that has been around that long it is inevitable that you will find more very old vulnerabilities, this isn't a bad thing and is simply a sign that even old code is still being reviewed and fixed.

Re:AHAHAHAHAH (2, Insightful)

Anonymous Coward | about 5 months ago | (#46402313)

How is this insightful? The only way this could be insightful is if the OP had said "This bug has existed since 2005, clearly we need greater adoption of open source software, to get more people interested in testing for bugs", because the option is closed software that has bugs no one can look at or fix.

I already have the the security update to this bug on all my machines, but if I had closed source who know when, if ever, a patch would have come.

Re:AHAHAHAHAH (0)

Anonymous Coward | about 5 months ago | (#46402485)

because the option is closed software that has bugs no one can look at or fix.

And yet people find bugs in closed software all the time without the source. And if the person has sufficient skill can even provide binary patches. Such as here [wikipedia.org] for example.

Re: AHAHAHAHAH (1)

Anonymous Coward | about 5 months ago | (#46403363)

They find them in proprietary software. That doesn't mean they get fixed.

Who was it this time (0)

Anonymous Coward | about 5 months ago | (#46401827)

NSA? GCHQ? The norks? No, the Syrians?

Now we'll find out... (3, Insightful)

Anonymous Coward | about 5 months ago | (#46401833)

...who has been surreptitiously using GPL'd code in their proprietary stacks...

Re:Now we'll find out... (2)

kthreadd (1558445) | about 5 months ago | (#46401929)

GnuTLS is actually under the lesser GPL.

Re:Now we'll find out... (3, Insightful)

WaffleMonster (969671) | about 5 months ago | (#46402179)

...who has been surreptitiously using GPL'd code in their proprietary stacks...

Why would anyone bother when they could just use OpenSSL and not have to worry about it?

Re:Now we'll find out... (0)

Anonymous Coward | about 5 months ago | (#46402395)

Why would anyone bother when they could just use OpenSSL and not have to worry about it?

Interesting question. I hadn't even realized there were two different SSL libraries available for Linux. Does anything imporant use GNU TLS?

Re:Now we'll find out... (0)

Anonymous Coward | about 5 months ago | (#46402517)

Why would anyone bother when they could just use OpenSSL and not have to worry about it?

Interesting question. I hadn't even realized there were two different SSL libraries available for Linux. Does anything imporant use GNU TLS?

Good question... this is the first I've ever heard of it.

Re: Now we'll find out... (0)

Anonymous Coward | about 5 months ago | (#46402597)

$ apt-cache rdepends gnutls

Nothing

Incompatible license (5, Informative)

tepples (727027) | about 5 months ago | (#46402607)

Re:Incompatible license (0)

Anonymous Coward | about 5 months ago | (#46403547)

The GPL has an exemption for linking with libraries that are part of the operating system. Otherwise you couldn't run GPLd applications on OS X or Solaris!

I use OpenSSL because it's available everywhere (except Windows) by default, and try to keep my project dependencies to a minimum (usually nil, because I target POSIX and POSIX-like systems.) That includes all the BSDs, OS X, popular Linux environments, and even Solaris. So as far as I'm concerned, OpenSSL is part of the OS. And that's also OpenSSL's interpretation. Just because you can roll a Linux environment without OpenSSL doesn't mean it can't still be considered part of the OS.

Also, there are libraries which mimic OpenSSL's API, at least the most prominent parts. For example, NSS, CyaSSL, etc. So for your typical GPL'd application doing something like SSL, it's hard to say that it "depends" on SSL if you can just swap out OpenSSL entirely with minimal or no changes to your code.

It's really just a bunch of fear mongering based on some less-than-ideal choices made 20 years ago. It would be really sweet if the original authors rescinded some of their terms, but they believe the whole thing is blown out of proportion and won't bend to pressure.

And at the end of the day, no open source SSL library gets hammered the way OpenSSL does, especially server-side. OpenSSL has the largest and most experienced developer based, and just because other libraries are newer and prettier doesn't mean that they're automatically safer or more reliable.

Re: Now we'll find out... (0)

Anonymous Coward | about 5 months ago | (#46402921)

The GnuTLS version of mod_ssl for apache supported SNI (virtual hosts over SSL) before the core did.

Fortunately not OpenSSL (2)

Carewolf (581105) | about 5 months ago | (#46401867)

Thank god it is in gnuTLS that is not used by any applications serious about security. Just checked, only printer drivers seems affected in my Debian installation.

God (0)

Anonymous Coward | about 5 months ago | (#46401895)

has nothing to do with it

Re:God (2, Funny)

Anonymous Coward | about 5 months ago | (#46401969)

It has gnu in the name. RMS is easily confused for the guy with the beard that people follow with religious vigor.

Roll your own (3, Funny)

goombah99 (560566) | about 5 months ago | (#46402279)

This is why you should always roll your own SSL scripts in php like the guy at Magic the Gathering Online Exchange did.

Concur. (0)

Anonymous Coward | about 5 months ago | (#46402339)

# aptitude why libgnutls26
i wget Depends libgnutls26 (>= 2.12.17-0)
#

In other news, open source code which few people care about does not receive adequate review.

Re:Concur. (1)

ChunderDownunder (709234) | about 5 months ago | (#46403479)

try removing that package from your system.

On mine, it warned about *a lot* of software that have it as an indirect dependency.

xubuntu seems to be completely dependent on gnutls (1)

Marrow (195242) | about 5 months ago | (#46402749)

Try to remove that library, and you find that most of the critical software depends on it.

Waiting for Microsoft's "Goto Fail" (1)

nicoleb_x (1571029) | about 5 months ago | (#46401909)

Just waiting for Microsoft's "Goto Fail" bug to surface. It may be too early to thank Snowden, but I'm starting to think I will have to at some point.

Re:Waiting for Microsoft's "Goto Fail" (1)

Ralph Wiggam (22354) | about 5 months ago | (#46401975)

Slashdot's response to a devastating bug in a GNU library?

Let's speculate about Microsoft's security and mention Snowden for no reason.

Re:Waiting for Microsoft's "Goto Fail" (0)

Anonymous Coward | about 5 months ago | (#46402031)

I think the insinuation was that the NSA sabotaged all these implementations.

Re:Waiting for Microsoft's "Goto Fail" (1)

Ralph Wiggam (22354) | about 5 months ago | (#46402711)

Is there no audit log on that code? It should be obvious whose code is responsible.

Even if the NSA put an exploit into the library in 2005, why didn't those millions of eyes I've heard so much about find the problem for 9 years?

Re:Waiting for Microsoft's "Goto Fail" (4, Interesting)

cbhacking (979169) | about 5 months ago | (#46402069)

I think it was MS who had a bug in the past where if I got a certificate issues for "google.com\0.attacker.com", I could present that certificate for a request to "google.com" (due to DNS hijacking or a MitM attack) and it would pass validation because the CN was handled as a C-style string and treated the null byte as a terminator. Fixed long ago, but still. People have been messing up cert validation for as long as it's been around.

The scary thing is how many mobile apps just don't *do* cert validation. Either it's completely disabled, or they crippled it in some way (I've seen both not checking the trust chain and not checking that the cert is valid for the target site). The usual reasons are "oh, we just did that for testing" (but I'm looking at your release version...) or "yeah, one of the servers it connects to uses a self-signed cert" (fine, add explicit trust *for that cert* but don't just disable chain-of-trust checks!) Another common problem is leaving completely broken or outdated options enabled (export ciphers - 40-bit symmetric crypto, easily breakable with a home PC - ot SSLv2 or other such similarly stupid things). Even if your platform/framework/library has a perfectly bug-free TLS implementation, few people ever seem to actually use it correctly.

Re:Waiting for Microsoft's "Goto Fail" (3, Informative)

Anonymous Coward | about 5 months ago | (#46402215)

It was a bug in multiple implementations of TLS including OpenSSL, NSS, and Microsoft's thing because they didn't expect cert authorities to give out certs with null bytes in the CN field.

Different Software - Same Problem (0)

Anonymous Coward | about 5 months ago | (#46401949)

Both these bugs are caused by people using 'goto' like morons. Using 'goto' should start throwing compile-time errors to start forcing people off this relic of flow control.

Re:Different Software - Same Problem (2, Informative)

Desler (1608317) | about 5 months ago | (#46401999)

No the issue was with conditionals and braces. The same issue would have happened even if it were two return statements .

Re:Different Software - Same Problem (3, Informative)

BasilBrush (643681) | about 5 months ago | (#46402095)

No the issue was with conditionals and braces. The same issue would have happened even if it were two return statements .

And a return statement before the end of a function is essentially a goto. A language that takes the step to rule out gotos should also not allow early returns.

Re:Different Software - Same Problem (3, Funny)

Sponge Bath (413667) | about 5 months ago | (#46402193)

Next, you'll be coming for my trigraphs and pointers. My precious.

Re:Different Software - Same Problem (2, Insightful)

Waffle Iron (339739) | about 5 months ago | (#46402275)

Yeah, force people to write a big pile of nested bracket spaghetti and manually back their way out of every case. Make them introduce a bunch of otherwise useless flag variables and extra conditional statements to keep track of it all.

The best part of it all: When all that extra obfuscation causes bugs, it would be harder to pin the root cause on a simplistic generalization like "goto === bad".

Re:Different Software - Same Problem (3, Informative)

BasilBrush (643681) | about 5 months ago | (#46402349)

Yeah, force people to write a big pile of nested bracket spaghetti...

1. "nested brackets" (blocks) are by definition not spaghetti. Spaghetti is exclusively the result of gotos and their control equivalents (like the early return).

2. Nested blocks are refactorable into smaller functions. That's the way to cut them down to size, not to use gotos.

I mean really! People still trying to argue with structured code in 2014! You'd think it was still the 1980s.

Function call overhead (2)

tepples (727027) | about 5 months ago | (#46402675)

Nested blocks are refactorable into smaller functions.

And the program eats the function/method/message call overhead, the overhead of passing all local variables as arguments, and the overhead of constructing and destroying an object through which to return multiple values from each function call.

Re:Function call overhead (1)

cnettel (836611) | about 5 months ago | (#46403549)

Nested blocks are refactorable into smaller functions.

And the program eats the function/method/message call overhead, the overhead of passing all local variables as arguments, and the overhead of constructing and destroying an object through which to return multiple values from each function call.

I think you need to be introduced to a modern optimizing compiler. It will handle the first two for you, just fine, as long as you are in the same compilation unit (or doing fancier global optimziation). Since you just refactored this from a single function, you are supposedly still in the same compilation unit. If you pack the data in something like a stack-allocated struct even the last one will be reduced or completely avoided.

Re:Different Software - Same Problem (2, Insightful)

lgw (121541) | about 5 months ago | (#46402733)

Wow, have you ever actually written production code? Just wow.

There's nothing cleaner than
if (input1 == null) {
        return ERROR("input1 was NULL");
    }
    if (input2 == null) {
        return ERROR("input2 was NULL");
    }
    if (input2 == null) {
        return ERROR("input3 was NULL");
    }

Substitute "throw new ERROR(..)" or "goto :error" depending on what kind of code your writing, it's the same thing any way you do it.

Nesting three levels deep before you even start to write real code? Garbage.

Re:Different Software - Same Problem (0)

lgw (121541) | about 5 months ago | (#46402791)

Wow, Slashcode totally sucks for formatting. WTF?

Re:Different Software - Same Problem (0)

cheesybagel (670288) | about 5 months ago | (#46402923)


for (int i=0; i<2; i++)
    if (!input[i]) return {snprintf(buf,sizeof(buf),"input%d was NULL", i+1); ERROR(buf);}

There fixed that you.

I actually looked at the snippet of the Apple TLS code once in an article. It could just as easily not used goto at all and it would have looked just as clean.

Re:Different Software - Same Problem (1)

Waffle Iron (339739) | about 5 months ago | (#46403281)

1. "nested brackets" (blocks) are by definition not spaghetti.

I called it spaghetti because the resulting mass of brackets looks just like a big steaming dish of spaghetti, and the extraneous control statements are almost as annoying as gotos to more than a single "error" label.

Nested blocks are refactorable into smaller functions. That's the way to cut them down to size, not to use gotos.

Some are, some not so much. Many situations call for a long list of sequential checks, which can be cleanly and clearly coded as a bunch of if .... return statements. If you put each case in a function you still have the following problems:
- If you do it the obvious way, you still need a deeply nested if-then chain. You haven't solved the problem.
- If you put each check within a function and daisy-chain them, you get creepy action-at-a-distance. It's not clear to the reader that you made a whole bunch of functions that should only be called from one place, and that they must be daisy chained.

I mean really! People still trying to argue with structured code in 2014! You'd think it was still the 1980s.

You seem hung up on definitions. If you narrowly define structured code as code that lacks return, break, continue and exception statements (which can all be used to break out of your "structured" sandbox), then plenty of people would argue with it in 2014.

The main problem with early exits is using them in C. But C is such an unsafe language in general, that's really the least of your worries. Other languages provide nice features like automatic destructors and "with" statements that make early exits perfectly reasonable.

Re:Different Software - Same Problem (1)

tepples (727027) | about 5 months ago | (#46402631)

Does Objective-C allow early returns?

Re:Different Software - Same Problem (1)

lister king of smeg (2481612) | about 5 months ago | (#46402189)

Both these bugs are caused by people using 'goto' like morons. Using 'goto' should start throwing compile-time errors to start forcing people off this relic of flow control.

Problem there is that it would break very old programs that just need recompiled and thus require a rewrite. A better way would be to have it disabled in the compiler by default so you have to enable a flag to override it so you are aware that it is there.

We all knew it was coming... (5, Informative)

neiras (723124) | about 5 months ago | (#46401963)

From February 16 2008: Howard Chu of OpenLDAP: GnuTLS Considered Harmful [openldap.org]

Looking across more of their APIs, I see that the code makes liberal use of strlen and strcat, when it needs to be using counted-length data blobs everywhere. In short, the code is fundamentally broken; most of its external and internal APIs are incapable of passing binary data without mangling it. The code is completely unsafe for handling binary data, and yet the nature of TLS processing is almost entirely dependent on secure handling of binary data.

Incredible that GnuTLS is used anywhere at all. It's just mind boggling.

Re:We all knew it was coming... (0)

Anonymous Coward | about 5 months ago | (#46402247)

That statement is 6 years old. Is it still true today though?

Re:We all knew it was coming... (0)

Anonymous Coward | about 5 months ago | (#46402503)

One would have to review the gnutls code to verify. As that's happening at an alarmingly slow rate, check back in a few years! /hopefully not anymore!

Re:We all knew it was coming... (0)

Anonymous Coward | about 5 months ago | (#46402549)

That statement is 6 years old. Is it still true today though?

Appearently yes.

Re:We all knew it was coming... (4, Informative)

sk999 (846068) | about 5 months ago | (#46402779)

Just downloaded the latest patched source code. Here's the summary:

find . -name '*.c' | xargs grep strlen | wc -l
522

find . -name '*.c' | xargs grep strcat | wc -l
44

Just as flawed as ever.

Re:We all knew it was coming... (0)

Anonymous Coward | about 5 months ago | (#46403211)

This should take an experienced C coder like a week to fix. Is the GNUtls project really that unmaintained/short on manpower?

Re:We all knew it was coming... (1)

CODiNE (27417) | about 5 months ago | (#46403143)

How come everyone and their brother haven't been turning in these for security bounties?

With enough eyes... NOT (4, Interesting)

williamyf (227051) | about 5 months ago | (#46401967)

I have always been critical about that conventional wisdom of "With enough eyeballs, all bugs are shallow".

I contend that is inacurate. With enough QUALIFIED AND MOTIVATED eyes, all bugs are shallow, and sometimes, some FOSS project lack enough Qualified eyes.

This bug, the KDE one, or even the Metafile bug in windows (and more importantly in WINE) among many others, show that many eyes are not enough.

Again one needs MOTIVATED AND QUALIFIED eyes AAAAAND good QA and test cases.

Cheers

Re:With enough eyes... NOT (3, Insightful)

rmstar (114746) | about 5 months ago | (#46402097)

Again one needs MOTIVATED AND QUALIFIED eyes AAAAAND good QA and test cases.

Perhaps using a safety aware language like Ada would be helpful too. C is known to be brittle, yet people insist in writing all sorts of mission critical code in it. I really wonder why.

Re:With enough eyes... NOT (0)

Anonymous Coward | about 5 months ago | (#46402871)

C is known to be brittle, yet people insist in writing all sorts of mission critical code in it. I really wonder why.

Because it's fast and a lot of people are familiar with it, and because lots of popular libraries don't have bindings for Ada - even with something like GNAT, generating these bindings can be a pain. Assembly language is substantially more brittle, but sometimes it's the tool needed for the job.

That's not to say that Ada's a bad language, but right now it's a lot easier to do most stuff in C/C++ IMO.

Re:With enough eyes... NOT (1)

Zalbik (308903) | about 5 months ago | (#46402755)

Damnit, it sounds like you are saying that software development is hard. And required diligence. And time.

That is NOT what my pointy-haired boss wants to hear.

He wants to hear that we can whip out software using cheap graduates of questionable schools, while distracting these developers with inane meetings, stupid corporate requirements (have you filled out you quarterly performance objectives?), and also making them the first-line software helpdesk and general IT support.

And he wants it all yesterday.

Diligence, motivation and qualification? That's crazy talk!

Severe, and yet not severe. (3, Informative)

Frobnicator (565869) | about 5 months ago | (#46401987)

The bug requires a carefully-crafted certificate. That certificate will verify as valid and trusted when it should not be. The connection will still be secure, it will just be with an untrusted person.

So basically it allows a very dedicated attacker to forge a cert and become a MitM attack.

We all know governments have done this for years. It is widely known that root CA certificates have been violated by spy agencies. A few searches on Google will show bunches of news stories where attackers (all types, government attackers, ID theft attackers, etc) have made fake certificates, abused the CA model, and engaged in similar MitM attacks to what this allows.

SSL/TLS communications are just as secure as they always were. If you have personally verified and trusted the certificates the attack wouldn't work, it is only when your trust model allows a cert that you don't personally trust to be used in authentication, and even then it still allows a secure connection but to a wrongly-trusted individual.

The flaw is the trust model and using a cert that you don't personally trust to be valid, which is a well-known issue.

Re:Severe, and yet not severe. (1)

Anonymous Coward | about 5 months ago | (#46402241)

> SSL/TLS communications are just as secure as they always were.

Yeah, I heard this song before back when PGP key signature parties were all the rage. Guess what? That "verify your keys" trick is about as scalable as collecting lip prints from your customers. It can be *fun*, but for other reasons, not for usable security. And yes, as a proof of concept, I forged and collected signatures for fake ID on GPG keys.

Re:Severe, and yet not severe. (0)

Anonymous Coward | about 5 months ago | (#46402249)

SSL/TLS communications are just as secure as they always were.

No, it is not.

CA model is much more important than the public CA "trust". There is nothing stopping an application designer from using private CAs for their application. This bug breaks the trust to any CAs, including the private ones.

Re:Severe, and yet not severe. (2, Insightful)

Anonymous Coward | about 5 months ago | (#46402271)

"The connection will still be secure, it will just be with an untrusted person."

What are you smoking? A connection with a MITM is not "secure". This is WORSE than sending data in plaintext.

Re:Severe, and yet not severe. (1)

tepples (727027) | about 5 months ago | (#46402707)

A connection with a MITM is not "secure". This is WORSE than sending data in plaintext.

Plaintext protocols also have a MITM. How is it any worse?

Re:Severe, and yet not severe. (0)

Anonymous Coward | about 5 months ago | (#46402891)

Because there is the expectation that the data is protected. If you know the link is insecure, then you don't transmit sensitive data. If you trust the link, then you may share sensitive data.

Re:Severe, and yet not severe. (0)

Anonymous Coward | about 5 months ago | (#46403159)

Is that really seriously a question?

This is TLS we're talking about. AKA "Transaction Layer Security"

If you don't understand the basics let me spell them out in simplistic words (please don't try to extrapolate beyond generalizations ... they won't hold up under a real mathematic analysis).

    * Data Confidentiality (it's secret from everybody but you & I)
    * Message Authentication (I am who I say I am, and you are who I think you are)
    * Message Integrity (What I send is what you get)

A necessary component of all of that is the 2nd bullet, validating -- who the fuck I'm talking to (I know who I am). If I don't know who I'm talking to, I don't have confidentiality because I might as well be talking to anybody. I probably don't have integrity. In general, without that authentication part, the other two fall to fucking pieces (and surprisingly fast if you perform any cryptographic operation without checking the MAC...)

The fact that it is sort of less open to a selected-uniformly-at-random person on the wire reading the message than comparable plaintext does not still mean you are *BETTER* than plaintext. It means you are more enciphered than plaintext. BIG HONKING FUCKING DEAL.

It means that people like you who think they know something get confused and transmit believing they are more protected than they really are. It means you failed in your most rudimentary and basic promise of "security" and as a result I am given a false feeling of confidence in a broadcast medium sending things that would not otherwise be sent. It means I do not even actually *have* a secure transport layer anymore.

In short, it means you totally, utterly fucked up.

The simple presence of a cryptographic cipher does not guarantee a private communication. FULL STOP.

That's why it's worse.

Because it's like me saying I'll watch your house while you're on vacation, but instead and I just say "fuck" it and go home. But somehow, people like you can't even tell that I went home immediately instead. So sleep soundly with your inflated sense of confidence and security under my watchful guard and broken promises. Don't call the neighbor if you think you left the stove on or tap running -- I'll notice it and fix it for you... I promise.

Re:Severe, and yet not severe. (2)

rritterson (588983) | about 5 months ago | (#46403443)

Your reasoning is a bit circular. This bug allows governments to do MitM attacks. Governments have already been doing MitM attacks, perhaps by exploiting this bug. Therefore, this bug is no big deal?

SSL/TLS communications are just as secure as they always where, which is to say broken in a widely used library under an implementation/trust model is that is very widely used.

Code audits (2, Interesting)

jones_supa (887896) | about 5 months ago | (#46402007)

I'm not sure if only "many eyes make bugs shallow" is enough, but that also professional, thorough code audits (like OpenBSD does) are needed to produce the most secure open source software. Any comments?

Re:Code audits (2, Interesting)

Burz (138833) | about 5 months ago | (#46402173)

Seems pretty clear that GnuTLS has too few eyes. Most everything uses OpenSSL instead, and that's where the eyes are concentrated.

Re:Code audits (0)

Anonymous Coward | about 5 months ago | (#46402283)

Gee, you mean like storing your 1024 bit, uber secure protected SSH keys unprotected and without a passphrase in $HOME/.ssh/id_dsa as a default? And providing no mechanism to *expire* or revoke bad SSH keys, or changed host keys, other than a text editor?

Yeah, that's real "secure". Secure like building your front door out of titanium and leaving the screws that hold it on outside, with a screwdriver tied to them.

So much for Linus's law. (4, Interesting)

BasilBrush (643681) | about 5 months ago | (#46402019)

"given enough eyeballs, all bugs are shallow"

Apple had their goto bug in TLS for about 18 months before they spotted it.

GnuTLS and therefore Linux has had their goto bug in TLS since 2005 (9 years) and it's only been spotted now as a result of the bow wave from Apple's disclosure.

Re:So much for Linus's law. (1)

Bert64 (520050) | about 5 months ago | (#46402153)

Only GnuTLS is not a default part of Linux, its an optional library used by some packages... Most packages seem to use OpenSSL instead, some offer a choice at compile time but most distros build for openssl by default.

I just "tried" to remove the library libgnutls26 (1)

Marrow (195242) | about 5 months ago | (#46402291)

An awful lot of stuff links to it. Browsers, flash, everything that dials out uses it on xubuntu. Are you saying that they are linking to it, but not using it? Or are they linking to it and then its using a wrapper to openssl.

Removing openssl invokes far fewer dependencies (1)

Marrow (195242) | about 5 months ago | (#46402319)

xubuntu appears to depend largely on the package that "everybody knows is shit".

This does not make me happy.

Re:I just "tried" to remove the library libgnutls2 (0)

Anonymous Coward | about 5 months ago | (#46402567)

GnuTLS in an independent TLS implementation, i.e. not an OpenSSL wrapper. It was created for the usual bad reason something with GNU embedded in the name is created; because FSF licenses aren't perfectly compatible with <insert some non-FSF copy-left> license, in this case OpenSSL's license(s).

As far as quality goes, I've never used it, but I doubt it's worse than OpenSSL. Because the OpenSSL "API" is one giant WTF.

Mageia (0)

Anonymous Coward | about 5 months ago | (#46402083)

Mageia 4 has already patched GnuTLS libraries yesterday.

Re:Mageia (0)

Anonymous Coward | about 5 months ago | (#46402131)

What the fuck kind of distro is Mangina?

Testing is hard (4, Interesting)

mveloso (325617) | about 5 months ago | (#46402135)

Testing is hard. The tools you have make it even harder.

How do you build a bad certificate? Fuck, using the openssl tools is hard enough. Does anyone who uses them really understand WTF is happening? I know I don't - I just follow the instructions.

How would you go about building a bogus cert? Beats me. I'm pretty sure you can't do it with the standard tools. And who the heck is going to write their own cert building tools?

And yet, this stuff is at the core of transport security.

Gnut possible (0)

Anonymous Coward | about 5 months ago | (#46402239)

Gnu way this is Gnue. Can't be Gnue. All those eyes, Gnuw and old, looking at this not Gnuw code, and Gnu one spotted anything. Wha? Yeah, buddy, Fuck Gnu Gnoo!

Mac and iOS not at risk (1)

noh8rz10 (2716597) | about 5 months ago | (#46402333)

Because if they were, the headline would have been zOMG mac and iOS not safe !!!!!!!11!!!!

The NSA is probably behind this (0)

Anonymous Coward | about 5 months ago | (#46402389)

Thanks Obama.

Ars Technica comments about open-source (1)

Thanosius (3519547) | about 5 months ago | (#46402633)

One thing I found interesting about the comments on Ars Technica about this article is that all comments regarding the (apparent) fallacy of open source allowing quick detection and turnaround of bugs tends to get very highly positively moderated, whereas the ones that argue that closed source software tends to limit the detection of such bugs and encourages sweeping detected bugs under the rug as much as possible get negatively modded or labelled "controversial".

One person even said this:

I would argue that closed source like Microsoft and Apple products might be more secure for two primary reasons: the software is so ubiquitous, it's exposed to orders of magnitude more users. By extension, more security experts are interested, so closed source doesn't stand in the way of people discovering vulnerabilities. And secondly, closed source software companies have a financial interest in their products that's harmed if they are insecure. No comment about Apple, but I know that Microsoft has put massive resources into making its products more secure.

Said comment was modded quite well. Yes, things like this get a lot of attention and look bad for the open-source movement, but keep in mind that open-source/free software is fully transparent. No-one can hide the details with FOSS, something that is far easier to do with closed source software. That level of transparency make it appear as though open-source has more bugs for longer. No-one outside of Microsoft and very select partners are able to audit Windows or Office. And yet the closed-source software is more secure?

It boggles the mind a tech site like Ars Technica can be so pro-closed source and anti-open source despite what I'd assume to be populated with geeks who should know better.

Re:Ars Technica comments about open-source (1)

gnoshi (314933) | about 5 months ago | (#46402773)

Well, if your starting point is that "open source doesn't lead to bugs being identified and disclosed" then those very posters you are complaining against are partially right, in part. Consider:
Open source: anyone can read the code, but (based on our premise) this doesn't lead to identification and disclosure of problems. It can allow a prospective attacker to identify problems and not disclose.
Closed source: only internal staff can read the code, but (based on our premise) having many eyes looking doesn't lead to identification and disclosure of problems. Prospective attackers can only do binary analysis, not source analysis, to find problems.

If binary analysis is more difficult than source analysis for finding potential bugs (i.e. potential targets for attack) then closed source is more secure in this context (assuming one or more attackers looking for potential vulnerabilities in the library/source/whatever).

Note: I'm not agreeing with the 'ubiquity' argument because it ignores read distributions of OSs. Also I'm not agreeing with the 'financial interest' arguments, because in a closed source there is the possibility that a company will gamble on an internally-detected vulnerability not being exploitable (or exploited) rather than fix it.

There are valid arguments for using open-source software, but I don't think the "many eyes" argument is necessarily a good one.

Re:Ars Technica comments about open-source (1)

Thanosius (3519547) | about 5 months ago | (#46403089)

Fair point. The "many eyes" argument might not hold well in practice, but from a personal perspective I feel more comfortable when important code at least has the opportunity to be analyzed by anyone due to it being open, as opposed to being under lock and key with only one vendor having access. At least the bug was fixed quickly.

So when a weakness like this is found (1)

Marrow (195242) | about 5 months ago | (#46402647)

Is everyone racing to change their passwords?

Well, this is embarrasing. (0)

Anonymous Coward | about 5 months ago | (#46402669)

I guess i should stop trolling #osx now then.

Deliberately introduced? (1)

mi (197448) | about 5 months ago | (#46402865)

The coding error may have been present since 2005

May it also be, the "coding error" was not an error at all, but a deliberately introduced bug? Government agencies always wanted to read our — and each other's — communications. Sometimes even for legitimate reasons...

*yawn* (0)

nurb432 (527695) | about 5 months ago | (#46402901)

Everything is vulnerable. its just a matter of how.

Freedom is better than dependency. (3, Insightful)

jbn-o (555068) | about 5 months ago | (#46403073)

So when Apple's proprietary encryption software suffered a problem, Apple users could do nothing but wait for Apple to deliver a fix; there's nobody else that are allowed to fix Apple's proprietary software but Apple. And when that fix ostensibly arrived, Apple users had to hope it wasn't bundled with some malware too (as is often in proprietary software [gnu.org] ).

This bug was caught during an audit [gnutls.org] —"The vulnerability was discovered during an audit of GnuTLS for Red Hat.". Nobody but the proprietor can audit proprietary software. But with free software, users have the freedom to audit the code they run, patch that code, and run their patched code; users can choose to fix bugs themselves or get someone else to fix bugs for them. And users don't have to always trust the same people to do work on their behalf. Users can also choose to wait for a fix to be distributed, and then they can choose to check that fix to make sure it doesn't contain malware. For all we know some users have long spotted and fixed this bug in GNUTLS. Since all complex software has bugs bugs are unavoidable. We're better off depending on people we choose to trust. Software freedom is better for its own sake.

Re:Freedom is better than dependency. (1)

cnettel (836611) | about 5 months ago | (#46403509)

The Apple library itself was open source, right (although rebuilding the OS files would be precarious in OS X and outright impossible in iOS)? The mess with libraries like this (proprietary or not) is all other code (proprietary or not) that not only link to shared objects provided with the OS, but roll their own, sometimes even modified, build of the library. Now, thanks to the fact that it's GPL it cannot be hidden in a blob without at least a license notice, but tracking it down everywhere will be a mess. And then we haven't even got started about embedded systems...
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...