New vulnerability found, GNUTLS lib, Linux possible target

[TWPonKubuntu]

New vulnerability found, Linux possible target

http://arstechnica.com/security/2014...eavesdropping/

"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...."

[richb]

New vulnerability found, Linux possible target

http://arstechnica.com/security/2014...eavesdropping/

"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...."

Changes came through today for GnuTLS on 13.10.

[GreyGeek]

That's good to hear, rb!

I noticed that the currently installed gnutls files on Kubuntu 14.04, as of the latest update at 11AM CST this morning are still using the 3.2.11-2ubuntu1 version.
https://www.kubuntuforums.net/showth...l=1#post346783

I suspect that sometime today the fix will come through the 14.04 repository.

[richb]

That's good to hear, rb!

I noticed that the currently installed gnutls files on Kubuntu 14.04, as of the latest update at 11AM CST this morning are still using the 3.2.11-2ubuntu1 version.
https://www.kubuntuforums.net/showth...l=1#post346783

I suspect that sometime today the fix will come through the 14.04 repository.

The version that came through is 2.12.23-1ubuntu4.1. I am sure 14.04 will come through soon.

[GreyGeek]

The version that came through is 2.12.23-1ubuntu4.1. I am sure 14.04 will come through soon.

How to mitigate the attack?

• Upgrade to the latest GnuTLS version (3.2.12 or 3.1.22), or apply the patch for GnuTLS 2.12.x.

Did the update say the patch was applied, or did it apply the patch to 2.12.x?

[Teunis]

The attack is not exactly hidden, the falsified certificate used will be presented as an exception that needs user approval.
At least that's how I read the various articles.

[richb]

Did the update say the patch was applied, or did it apply the patch to 2.12.x?

The way I read it, it was incorporated into 2.12.23. I did not see any mention of a patch.

[GreyGeek]

I've been back-tracking on the guntls problem and noticed a couple things. First, the ARS article claims that:

The coding error, which may have been present in the code since 2005, causes critical verification checks to be terminated,

The Chief Architect for ldap, Howard Chu, states in comment #72 of a bug report on this issue in 2010, four years ago, that:

I read all of the diffs between 1.4.1 and 1.4.4 but didn't find any likely suspects. However, tracing the library initialization in gdb, I found the specific problem.
Ordinarily gnutls will initialize the gcrypt library, if no app has done so already. In the gnutls initialization, it specifically turns gcrypt's secure malloc off, and everything works fine.
However, in my trace on Lucid, libnss-ldap is linked to libldap_r, not libldap. And because libldap_r has to support threads, it is required to initialize libgcrypt's thread callbacks, and it must do this before doing anything else with libgcrypt or gnutls.
http://www.gnupg.org/documentation/m..._002dThreading
The problem with that is, once we do this thread initialization, libgcrypt considers itself fully initialized. When we next call gnutls's init function, it checks to see if gcrypt is init'd or not, sees that it is, and skips any further init'ing. So the secure malloc stuff remains enabled.

So, the bug is not new and has been worked on for many years, even by Chu himself, who made a patch in #73, and in 2008 post stated:

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.

That 2008 thread was also used as an opportunity by some to bash the GPL's "lack of cooperation" with other licenses.

Chu repeats this theme four years later in a comment on the ARS article. His recommendation of four years ago, before and since then, has always been, of course (#55), to drop gnutls and use libnss-ldapd.

Regardless of what the root cause turns out to be, you guys really need to switch to libnss-ldapd, which will reliably isolate the user apps from whatever junk is going on inside libldap / gnutls / whatever.

It turns out that the RH security programmer who discovered the problem is none other than

The CVE-2014-0092 issue was discovered by Nikos Mavrogiannopoulos of the
Red Hat Security Technologies Team.

the programmer who wrote the code in 2003, Nikos Mavrogiannopoulos.

So, the problems with gnutls are not new and there have been many bugs and patches on that code, just like most other pieces of both GPL code. The problem has been found, and in some cases already patched, with more patches coming down the line. As far as risk goes, all someone has to do is point out a security breach that can be attributed to gnutls to prove that the bad guys found the hole before Nick did. I doubt that anyone can, or we would have head about it on the NYT front pages.

[GreyGeek]

HUGE update this morning...

gnutls26 (2.12.23-12ubuntu2) trusty; urgency=medium

* SECURITY UPDATE: certificate validation bypass
- debian/patches/CVE-2014-0092.patch: correct return codes in
lib/x509/verify.c.
- CVE-2014-0092

[MoonRise]

Yep! Got it here!