Biz & IT —
This GnuTLS bug is worse than the big Apple "goto fail" bug patched last week.
Dan Goodin -
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.
"It was discovered that GnuTLS did not correctly handle certain errors that could occur during the verification of an X.509 certificate, causing it to incorrectly report a successful verification," an advisory issued by Red Hat warned. "An attacker could use this flaw to create a specially crafted certificate that could be accepted by GnuTLS as valid for a site chosen by the attacker."
GnuTLS developers published this bare-bones advisory that urges all users to upgrade to version 3.2.12. The flaw, formally indexed as CVE-2014-0092, is described by a GnuTLS developer as "an important (and at the same time embarrassing) bug discovered during an audit for Red Hat." Debian's advisory is here.
Distant relative of “goto fail”
Further Reading
New iOS flaw makes devices susceptible to covert keylogging, researchers say
As was the case with last week's critical encryption bug from Apple, the GnuTLS vulnerability is the result of someone making mistakes in source code that controls critical functions of the program. This time, instead of a single misplaced "goto fail" command, the mistakes involve errors with several "goto cleanup" calls. The GnuTLS program, in turn, prematurely terminates code sections that are supposed to establish secure TLS connections only after the other side presents a valid X509 certificate signed by a trusted source. Attackers can exploit the error by presenting vulnerable systems with a fraudulent certificate that is never rejected, despite its failure to pass routine security checks. The failure may allow attackers using a self-signed certificate to pose as the cryptographically authenticated operator of a vulnerable website and to decrypt protected communications. It's significant that no one managed to notice such glaring errors, particularly since they were contained in code that anyone can review.
Security researchers are still studying the vulnerability and assessing its effect on the wide array of OSes and applications that depend on GnuTLS. For the moment, readers should assume that the severity is critical given the dizzying amount of downstream code that may be affected. One example: the apt-get installer some distributions of Linux use to distribute and update applications relies on GnuTLS, although exploits against the package can probably be caught by cryptographic code-signing of the downloaded program (thanks to readers for pointing out this secondary level of protection). Version 3 of lib-curl, which is distributed in Debian and Ubuntu, also depends on GnuTLS. Some Debian- and Ubuntu-based virtual private networking applications that work with Cisco Systems hardware are also affected. This list goes on and on.
Matt Green, a Johns Hopkins University professor specializing in cryptography, characterized the vulnerability this way: "It looks pretty terrible."
Kenneth White, a principal security engineer of Social & Scientific Systems, agreed, saying the vulnerability "has a lot of side effects."
This article will be updated if important additional details become available.
Article updated to add details in fourth-to-last paragraph. Article updated to correct misstatements about Cisco virtual private networking software.
Promoted Comments
-
hycSmack-Fu Master, in training "I told you so"
-
xcrunner529Ars Praefectuset Subscriptor Can someone explain to me how we didn't notice these things in both Linux and iOS for years? I mean, wouldn't people setting up SSL sites and stuff wonder why a certain certificate would actually be trusted...or know when to expect an error, but instead see the cert working? It seems like that would be noticable.
-
MattGertzSmack-Fu Master, in training dethschyld wrote:
ok i have to ask, other than deeply nested loops and coding in assembly, why would anyone use a goto statement in any modern language?
i remember the first sentence my first coding professor said because he restated it every day of class, "if i see a goto statement in code you fail this class." every coding class i ever took the professor said the same thing. its just bad practice so why would a widely used open source do this?
Goto certainly increases your odds of this sort of problem, no question. But IMO goto isn't the problem -- sloppy code planning & reviews are the problem. For example, let's think of something more bizarre than goto: consider a code statement set that could allow code execution to suddenly switch from *any* line of code within a certain range, under a wide variety of circ*mstances, to another specific part of the code. Described that way (and admittedly, I'm stretching a point), such a thing sounds bizarre, but in fact many of us use try-catch-finally (or it's equivalent) on a daily basis, and most (though not all) would argue that it's a good thing. But if you leave out the "finally" without catching & reacting to the total possible exceptions, or forget to include the right clean-up code in the "finally" or "catch" blocks (as appropriate), you could be in exactly the same state as you'd get with goto (particularly if you swallow the exception) -- except with goto, you're at least stating explicitly that the specific line of code preceding the goto may end up causing an execution shift, every time you use it.
Now, I'm not advocating for goto (I find it to be sloppy), and I am a big fan of exception handling. But I reckon that there are lots of ways to mess yourself up exactly as in these cases that don't involve goto.
-
diskreteSmack-Fu Master, in training If only this had been an open source TLS library, this wouldn’t have happened. [/s]
Seriously, though, “many eyes” only works if people who actually understand the code take the time to study it. It’s not exciting work, but it’s essential.
-
hycSmack-Fu Master, in training Certainly, the fact that a project is Open Source is no guarantee of its quality. As coders you have to know WTF you're doing, and the GnuTLS authors clearly didn't/don't. It's as if one day someone decided "I'm going to write a TLS library! Just one thing, what's TLS?"
See AlsoWhen Will The Bear Market End?The GnuTLS guys knew nothing about X.509 certificates, which are fundamental to TLS security. They knew nothing about software architecture, which led to numerous problems such as documented here
https://bugs.launchpad.net/debian/+sour ... bug/423252
In particular, they created a library (libgcrypt) with usage requirements ("the calling application must call this init function before any other use of the library") that were impossible to meet in the real world. (Because pam or nss might be using the security library, and any application would be using it indirectly, and have no knowledge that libgcrypt was running underneath, and have no way of meeting its initialization requirements.)
I didn't just say the code was bad. I said the code was clearly written by people who didn't know what they were doing, and it would take a complete rewrite *by competent programmers* to make it usable. The design was bad, not just the implementation.
-
BioTurboNickArs Scholae Palatinae How many times do we hear the mantra "Open Source is more secure than Closed Source because many people can look at it"?
This is the context for "Open Source basically means nothing." -- in terms of inherent security and bugs, it *doesn't* mean much.
The only way to assure security is to have many highly-competent programmers writing, looking at, and testing a chunk of code as fully as possible. This is true of both closed and open source projects. You don't guarantee those things in open source.
Promoted Comments
-
hycSmack-Fu Master, in training "I told you so"
-
xcrunner529Ars Praefectuset Subscriptor Can someone explain to me how we didn't notice these things in both Linux and iOS for years? I mean, wouldn't people setting up SSL sites and stuff wonder why a certain certificate would actually be trusted...or know when to expect an error, but instead see the cert working? It seems like that would be noticable.
-
MattGertzSmack-Fu Master, in training dethschyld wrote:
ok i have to ask, other than deeply nested loops and coding in assembly, why would anyone use a goto statement in any modern language?
i remember the first sentence my first coding professor said because he restated it every day of class, "if i see a goto statement in code you fail this class." every coding class i ever took the professor said the same thing. its just bad practice so why would a widely used open source do this?
Goto certainly increases your odds of this sort of problem, no question. But IMO goto isn't the problem -- sloppy code planning & reviews are the problem. For example, let's think of something more bizarre than goto: consider a code statement set that could allow code execution to suddenly switch from *any* line of code within a certain range, under a wide variety of circ*mstances, to another specific part of the code. Described that way (and admittedly, I'm stretching a point), such a thing sounds bizarre, but in fact many of us use try-catch-finally (or it's equivalent) on a daily basis, and most (though not all) would argue that it's a good thing. But if you leave out the "finally" without catching & reacting to the total possible exceptions, or forget to include the right clean-up code in the "finally" or "catch" blocks (as appropriate), you could be in exactly the same state as you'd get with goto (particularly if you swallow the exception) -- except with goto, you're at least stating explicitly that the specific line of code preceding the goto may end up causing an execution shift, every time you use it.
Now, I'm not advocating for goto (I find it to be sloppy), and I am a big fan of exception handling. But I reckon that there are lots of ways to mess yourself up exactly as in these cases that don't involve goto.
-
diskreteSmack-Fu Master, in training If only this had been an open source TLS library, this wouldn’t have happened. [/s]
Seriously, though, “many eyes” only works if people who actually understand the code take the time to study it. It’s not exciting work, but it’s essential.
-
hycSmack-Fu Master, in training Certainly, the fact that a project is Open Source is no guarantee of its quality. As coders you have to know WTF you're doing, and the GnuTLS authors clearly didn't/don't. It's as if one day someone decided "I'm going to write a TLS library! Just one thing, what's TLS?"
The GnuTLS guys knew nothing about X.509 certificates, which are fundamental to TLS security. They knew nothing about software architecture, which led to numerous problems such as documented here
https://bugs.launchpad.net/debian/+sour ... bug/423252
In particular, they created a library (libgcrypt) with usage requirements ("the calling application must call this init function before any other use of the library") that were impossible to meet in the real world. (Because pam or nss might be using the security library, and any application would be using it indirectly, and have no knowledge that libgcrypt was running underneath, and have no way of meeting its initialization requirements.)
I didn't just say the code was bad. I said the code was clearly written by people who didn't know what they were doing, and it would take a complete rewrite *by competent programmers* to make it usable. The design was bad, not just the implementation.
-
BioTurboNickArs Scholae Palatinae How many times do we hear the mantra "Open Source is more secure than Closed Source because many people can look at it"?
This is the context for "Open Source basically means nothing." -- in terms of inherent security and bugs, it *doesn't* mean much.
The only way to assure security is to have many highly-competent programmers writing, looking at, and testing a chunk of code as fully as possible. This is true of both closed and open source projects. You don't guarantee those things in open source.
