First goto fail, now something Gnu

Just a week ago the masses were screaming for blood over the "goto fail" bug that compromised SSL communications in both iOS and OS X. There was no shortage of noise in the echo chamber of social media. 

Fast forward one week.

Now we see that there is a problem in GnuTLS which by some accounts is far worse. But, where is the outcry this time? 



A vulnerability was discovered that affects the certificate verification functions of all gnutls versions. A specially crafted certificate could bypass certificate validation checks. The vulnerability was discovered during an audit of GnuTLS for Red Hat.

Where is the outrage? How long was this problem in place? I wondered this and I started doing some digging. 

From the Open LDAP mailing list we find this,

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.


I strongly recommend that GnuTLS not be used. All of its APIs would need to be overhauled to correct its flaws and it's clear that the developers there are too naive and inexperienced to even understand that it's broken.

To put a fine point on it...this posting was from February 2008. There may even be other instances further back. This gets me wondering, are we not WAY overdue for code audits on security related projects? 

I made a smart ass remark on Twitter about the reactions to goto fail vs GnuTLS and I received this in reply,

@gattaca meanwhile in OpenSSL, gotos and lack of braces in cert verification...

— David Dahl (@deezthugs) March 5, 2014

(Image used under CC from REL Waldman)

Copyright © 2014 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)