Bugzilla Bug 90726

Announcement email:
http://lists.gnupg.org/pipermail/gnutls-dev/2005-April/000858.html

*** Bug 90733 has been marked as a duplicate of this bug. ***

added 1.2.3 and 1.0.25.

For the advisory can something like the following be scripted:

"Because of small API changes with the previous version please do the following to ensure your applications are using the latest gnutls that you just emerged.

revdep-rebuild --soname-regexp libgnutls.so.1[0-1] -- -p

If any packages are shown then do:

revdep-rebuild --soname-regexp libgnutls.so.1[0-1]

Arches although stabilising to 1.2.3 isn't required for the security bug Tom Martin <slarti> and myself would really appreciate it if you did. This is the recognised stable version upstream and very few problems have been reported on it (an none of them were the fault of gnutls). The main reason is I'd rather see the update occur with the clear instruction of the revdep-rebuild (in addition to the post install message).

Target:
1.0.25: alpha amd64 arm hppa ia64 mips ppc ppc64 sparc x86

Requested target *please*:
1.2.3: x86 sparc ppc amd64 mips alpha ppc64

test strategy: Elfyn <beu> and I tested the gnutls by emerging gaim with the USE=gnutls flag and instigating an encrypted session.

stable on ppc64

Already marked stable on ppc by dragonheart.

stable on amd64

Stable on hppa.

sparc stable.

Alpha + ia64 stable.

Ready for GLSA.

For the GLSA  put: emerge -C gnutls before emerging the new version.

As seen in bug 91012 this links to the old version.

from:

news://news.gmane.org/gmane.network.gnutls.general

(http - http://news.gmane.org/gmane.network.gnutls.general isn't up to date yet)

Extract from news://

The problem was discovered by INL when we were studying a crash of
nuauth, a daemon which is part of the NuFW project
(http://www.nufw.org). During stress test we made on our solution, we
open a lot of tls sessions simultaneously (more than 200). After some
times the application crash with a segfault.

.
..
.
.
.
(detailed code analysis)
.
.
.

To sum up the error was the following : 

code computes value relative to the size of an array with two methods
without taking care that this could lead to out of the array indexes. In
fact, this is a case of badly checked entry from user (even it is really
low level). This bug is quiet severe as it should be easy to forge a
packet where the two values are different.

As gnutls_decrypt is called as soon as the application try to handshake,
the bug can be exploited by unauthenticated users. So theoritically all
applications running gnutls are vulnerable to this distant denial of
service available even for unauthenticated users.

BR,

from:

news://news.gmane.org/gmane.network.gnutls.general

(http - http://news.gmane.org/gmane.network.gnutls.general isn't up to date yet)

Extract from news://

The problem was discovered by INL when we were studying a crash of
nuauth, a daemon which is part of the NuFW project
(http://www.nufw.org). During stress test we made on our solution, we
open a lot of tls sessions simultaneously (more than 200). After some
times the application crash with a segfault.

.
..
.
.
.
(detailed code analysis)
.
.
.

To sum up the error was the following : 

code computes value relative to the size of an array with two methods
without taking care that this could lead to out of the array indexes. In
fact, this is a case of badly checked entry from user (even it is really
low level). This bug is quiet severe as it should be easy to forge a
packet where the two values are different.

As gnutls_decrypt is called as soon as the application try to handshake,
the bug can be exploited by unauthenticated users. So theoritically all
applications running gnutls are vulnerable to this distant denial of
service available even for unauthenticated users.

BR,
Éric Leblond, eleblond@inl.fr
Téléphone : 01 44 89 46 40, Fax : 01 44 89 45 01
INL, http://www.inl.fr

GLSA 200505-04

Versions will have to be corrected in case a newer 1.0.x ebuild gets committed or it will appear vulnerable.

Stable on mips.