GnuTLS Bug Puts Network Communications at Risk

A week ago Apple reported the goto fail bug, a logical coding error in the Mac OS X and iOS implementations of a TLS shared library. Yes, it really happened at a goto statement jumping execution to a code block handling failure.

This week the open-source community had egg on its crowd-sourced face as we discovered that the “many eyes” model still let a somewhat similar TLS bug linger in the GnuTLS package since 2003. It’s similar in that it breaks the same thing (verification of an x509.v3 digital certificate) with the same end result (a carefully crafted invalid certificate causes a logical failure and error-handling checks stop too soon) and it happens around an invocation of the same antiquated and long-disparaged goto directive.

Officially, it’s CVE-2014-0092. Unofficially, there is plenty of speculation that these are both NSA-planted back doors with the goal of masquerading as a legitimate server and stealing information from client devices and applications.

In Learning Tree’s System and Network Security Introduction course we talk about the need to patch software as soon as practical. This is a case where it’s especially important, as the bug is in a critical security component.

What’s involved, what does that mean, and what should we do?

GnuTLS is a shared library, meaning that it’s not an application you directly use on its own, but it is used by many applications and so it is effectively part of all of them. A bug in a shared library is a bug in every executable program that uses it. These could be small user applications that don’t communicate over a network, but the risk is high here because most applications using GnuTLS will be networked client or server programs for which we are relying on GnuTLS to provide security.

Specifically, this GnuTLS bug is in the certificate verification process, an early stage of setting up a network connection protected by TLS or Transport Layer Security, the follow-on to SSL or Secure Sockets Layer. There’s no point in whispering secrets to strangers, so you start by verifying the identity of the remote system. This involves a digital certificate issued by a trusted third party, or at least it is supposed to. This bug causes a program to inappropriately accept a self-signed certificate.

For a physical world analogy, imagine if you made a fake FBI badge with a piece of cardboard and a crayon, and then you confused someone while they were looking at it. They certainly didn’t verify that it is real, because it isn’t. But their confusion caused them to stop in the middle of realizing that it’s bogus. “I didn’t notice that it was bogus, so I suppose it’s real, and so you must be a real FBI agent.”

Meanwhile, every application relying on GnuTLS is at risk. Patch your GnuTLS shared library code now.

The good news here is that patching this one shared library fixes all the programs that rely on it, you don’t have to track down all of them and fix them, too.

Next week I’ll tell you more. Get to patching, we’ll talk then.

Bob Cromwell

Type to search blog.learningtree.com

Do you mean "" ?

Sorry, no results were found for your query.

Please check your spelling and try your search again.