Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 90726 - net-libs/gnutls DoS < 1.2.3 and < 1.0.25
Summary: net-libs/gnutls DoS < 1.2.3 and < 1.0.25
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Gentoo Security
URL:
Whiteboard: A3 [glsa+] jaervosz
Keywords:
: 90733 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-04-28 08:51 UTC by Paul Querna
Modified: 2005-08-15 22:10 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Querna 2005-04-28 08:51:14 UTC
Announcement email:
http://lists.gnupg.org/pipermail/gnutls-dev/2005-April/000858.html
Comment 1 Daniel Black (RETIRED) gentoo-dev 2005-04-28 13:39:28 UTC
*** Bug 90733 has been marked as a duplicate of this bug. ***
Comment 2 Daniel Black (RETIRED) gentoo-dev 2005-04-28 15:33:18 UTC
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.
Comment 3 Markus Rothe (RETIRED) gentoo-dev 2005-04-29 01:26:45 UTC
stable on ppc64
Comment 4 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-04-29 10:08:33 UTC
Already marked stable on ppc by dragonheart.
Comment 5 Jan Brinkmann (RETIRED) gentoo-dev 2005-04-29 10:52:59 UTC
stable on amd64
Comment 6 Michael Hanselmann (hansmi) (RETIRED) gentoo-dev 2005-04-29 12:34:08 UTC
Stable on hppa.
Comment 7 Gustavo Zacarias (RETIRED) gentoo-dev 2005-04-29 15:40:17 UTC
sparc stable.
Comment 8 Bryan Østergaard (RETIRED) gentoo-dev 2005-04-29 17:05:26 UTC
Alpha + ia64 stable.
Comment 9 Luke Macken (RETIRED) gentoo-dev 2005-04-29 17:11:58 UTC
Ready for GLSA.
Comment 10 Daniel Black (RETIRED) gentoo-dev 2005-05-01 05:14:23 UTC
For the GLSA  put: emerge -C gnutls before emerging the new version.

As seen in bug 91012 this links to the old version.
Comment 11 Daniel Black (RETIRED) gentoo-dev 2005-05-04 01:42:38 UTC
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,
Comment 12 Daniel Black (RETIRED) gentoo-dev 2005-05-04 01:42:38 UTC
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
Comment 13 Matthias Geerdsen (RETIRED) gentoo-dev 2005-05-09 02:06:19 UTC
GLSA 200505-04

Versions will have to be corrected in case a newer 1.0.x ebuild gets committed or it will appear vulnerable.
Comment 14 Hardave Riar (RETIRED) gentoo-dev 2005-07-03 14:21:55 UTC
Stable on mips.