Critical GnuTLS Crypto Bug In Linux


Recommended Posts

By Dan Goodin Mar 5 2014, 5:56am AEST

Dan Goodin from Arstechnica, reports that "Critical crypto bug leaves Linux, hundreds of apps open to eavesdropping"

This GnuTLS bug is worse than the big Apple "goto fail" bug patched last week.

Hundreds of open source packages, including the Red Hat, Ubuntu, and Debian distributions of Linux, are susceptible to attacks that circumvent the most widely used technology to prevent eavesdropping on the Internet, thanks to an extremely critical vulnerability in a widely used cryptographic code library.

The 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 bug is the result of commands in a section of the GnuTLS code that verify the authenticity of TLS certificates, which are often known simply as X509 certificates. The coding error, which may have been present in the code since 2005, causes critical verification checks to be terminated, drawing ironic parallels to the extremely critical "goto fail" flaw that for months put users of Apple's iOS and OS X operating systems at risk of surreptitious eavesdropping attacks. Apple developers have since patched the bug.

Full Source Arstechnica

 

I am still trying to figure out how to post properly to the right thread so I was not sure this belongs here or Linux section :)

Link to comment
Share on other sites

Uh oh, here we go again.  So Windows is actually the most secure right now? :p

Until an even worse bug is found in Windows HTTPS (well IE's implementation) next week ;-)

Link to comment
Share on other sites

Thank god for Snowden! If it wasn't for him, we would still be blind to the massively insecure infrastructure we currently use. It's awesome how everybody is scrambling to fix current holes and finding new ones to be fixed. No OS is ever 100% secure and perfect. Hopefully this will be patched in the coming days.   

Link to comment
Share on other sites

One good thing about Linux distros is, they can push out patches for critical issues like this pretty quickly compared to Windows/Mac.

 

Because nobody uses it thus they don't have to worry about breaking anything.

Link to comment
Share on other sites

Because nobody uses it thus they don't have to worry about breaking anything.

Except for everywhere in the server world  :rolleyes:

Link to comment
Share on other sites

Except for everywhere in the server world  :rolleyes:

 

So then why would they

 

push out patches for critical issues like this pretty quickly compared to Windows/Mac.

 

 

WIthout properly testing it first.

Link to comment
Share on other sites

So then why would they

 

 

WIthout properly testing it first.

Patching simple bugs like this shouldn't take more than a day. It's not like this is a re-implementation or a complex bug. MS/Apple could do the same things if they wanted to in these sort of cases.

Link to comment
Share on other sites

Ouch, as far back as 2005.  At least the patch is being pushed quickly... better check my servers later.

Link to comment
Share on other sites

Ouch, as far back as 2005.  At least the patch is being pushed quickly... better check my servers later.

 

honestly, this doesn't surprise me. at all; back in 99 i knew a few groups that had 0day exploits and were actively using them (for Linux/BSD/Windows and for several BDs); as far as i know some were patched, some are still unknown (and this is the problem).

Link to comment
Share on other sites

1. Don't use goto

2. Don't have a situation where, if a function does get exited when it shouldn't, the value returned is a valid result

3. Don't mix things like validation logic in with code such as clean up code, separate them

Link to comment
Share on other sites

1. Don't use goto

2. Don't have a situation where, if a function does get exited when it shouldn't, the value returned is a valid result

3. Don't mix things like validation logic in with code such as clean up code, separate them

There are certain situations where goto is useful for optimization and clarity purposes: this is the primary reason it is used in the Linux Kernel (and elsewhere in practice). In this particular case, goto isn't to blame for the error.

Link to comment
Share on other sites

Yeah, the goto has nothing to do with this bug, looks like they weren?t initialising a return value properly (The commit linked in the ars article is basically just them initialising a variable properly) And one of the things crypto libraries often want is uninitialised memory, so those errors are often ignored (The Debian OpenSSL bug was caused by one of the Debian guys paying attention to the warning and fixing it, breaking the code)

Even in the Apple case, the goto wasn?t the actual flaw, the flaw was a logic error (It could have easily been a function call, etc.) It would have been caught if the compiler was checking for unreachable code, which it wasn?t for whatever reason (It seems Clang doesn?t include that warning as the ones enabled when asking for ?all warnings?)

  • Like 1
Link to comment
Share on other sites

Honestly it just reflects extremely poorly on the maintainers of the code.  It's shocking that they don't even have a simple negative test for this code path, especially when doing large refactoring work having that functional check is crucial. 

 

Of course there's always #NSA, heh.

Link to comment
Share on other sites

This topic is now closed to further replies.