Git-Url: http://git.frugalware.org/gitweb/gitweb.cgi?p=frugalware-current.git;a=commitdiff;h=889eae53316c6d703bbab1b6f64d446e749ec1bd
commit 889eae53316c6d703bbab1b6f64d446e749ec1bd Author: voroskoi <[EMAIL PROTECTED]> Date: Sun Sep 28 21:54:24 2008 +0200 gnutls-2.4.2-1-x86_64 remove patch, in upstream diff --git a/source/lib/gnutls/CVE-2008-2377.patch b/source/lib/gnutls/CVE-2008-2377.patch deleted file mode 100644 index 86edeeb..0000000 --- a/source/lib/gnutls/CVE-2008-2377.patch +++ /dev/null @@ -1,185 +0,0 @@ -Path: news.gmane.org!not-for-mail -From: Simon Josefsson <[EMAIL PROTECTED]> -Newsgroups: gmane.comp.encryption.gpg.gnutls.devel -Subject: Details on the gnutls_handshake local crash problem - [GNUTLS-SA-2008-2] -Date: Mon, 30 Jun 2008 23:42:18 +0200 -Lines: 118 -Approved: [EMAIL PROTECTED] -Message-ID: <[EMAIL PROTECTED]> -NNTP-Posting-Host: lo.gmane.org -Mime-Version: 1.0 -Content-Type: text/plain; charset=us-ascii -X-Trace: ger.gmane.org 1214862206 30279 80.91.229.12 (30 Jun 2008 21:43:26 GMT) -X-Complaints-To: [EMAIL PROTECTED] -NNTP-Posting-Date: Mon, 30 Jun 2008 21:43:26 +0000 (UTC) -To: [EMAIL PROTECTED] -Original-X-From: [EMAIL PROTECTED] Mon Jun 30 23:44:12 2008 -Return-path: <[EMAIL PROTECTED]> -Envelope-to: [EMAIL PROTECTED] -Original-Received: from lists.gnu.org ([199.232.76.165]) - by lo.gmane.org with esmtp (Exim 4.50) - id 1KDRAR-0005Ih-0g - for [EMAIL PROTECTED]; Mon, 30 Jun 2008 23:44:11 +0200 -Original-Received: from localhost ([127.0.0.1]:37837 helo=lists.gnu.org) - by lists.gnu.org with esmtp (Exim 4.43) - id 1KDR9a-0002I5-On - for [EMAIL PROTECTED]; Mon, 30 Jun 2008 17:43:18 -0400 -Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) - id 1KDR8k-0001yM-Pz - for [EMAIL PROTECTED]; Mon, 30 Jun 2008 17:42:26 -0400 -Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) - id 1KDR8j-0001xK-ME - for [EMAIL PROTECTED]; Mon, 30 Jun 2008 17:42:26 -0400 -Original-Received: from [199.232.76.173] (port=44168 helo=monty-python.gnu.org) - by lists.gnu.org with esmtp (Exim 4.43) id 1KDR8j-0001xD-FA - for [EMAIL PROTECTED]; Mon, 30 Jun 2008 17:42:25 -0400 -Original-Received: from yxa-v.extundo.com ([83.241.177.39]:54450) - by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) - (Exim 4.60) (envelope-from <[EMAIL PROTECTED]>) id 1KDR8i-0003tj-UH - for [EMAIL PROTECTED]; Mon, 30 Jun 2008 17:42:25 -0400 -Original-Received: from yxa.extundo.com ([83.241.177.38] helo=mocca.josefsson.org) - by yxa-v.extundo.com with esmtpa (Exim 4.63) - (envelope-from <[EMAIL PROTECTED]>) id 1KDR8c-0000pM-H9 - for [EMAIL PROTECTED]; Mon, 30 Jun 2008 23:42:23 +0200 -X-Hashcash: 1:22:080630:[EMAIL PROTECTED]::vPIbwkOzpmpCCZql:668Q -OpenPGP: id=B565716F; url=http://josefsson.org/key.txt -User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.2 (gnu/linux) -X-detected-kernel: by monty-python.gnu.org: Genre and OS details not - recognized. -X-BeenThere: [EMAIL PROTECTED] -X-Mailman-Version: 2.1.5 -Precedence: list -List-Id: GnuTLS development discussions <gnutls-devel.gnu.org> -List-Unsubscribe: <http://lists.gnu.org/mailman/listinfo/gnutls-devel>, - <mailto:[EMAIL PROTECTED]> -List-Archive: <http://lists.gnu.org/pipermail/gnutls-devel> -List-Post: <mailto:[EMAIL PROTECTED]> -List-Help: <mailto:[EMAIL PROTECTED]> -List-Subscribe: <http://lists.gnu.org/mailman/listinfo/gnutls-devel>, - <mailto:[EMAIL PROTECTED]> -Original-Sender: [EMAIL PROTECTED] -Errors-To: [EMAIL PROTECTED] -Xref: news.gmane.org gmane.comp.encryption.gpg.gnutls.devel:2948 -Archived-At: <http://permalink.gmane.org/gmane.comp.encryption.gpg.gnutls.devel/2948> - -Below is my analysis of the problem. The patch is short: - -From 0fee3917077e191dea3c9787c95c072979532086 Mon Sep 17 00:00:00 2001 -From: Simon Josefsson <[EMAIL PROTECTED]> -Date: Mon, 30 Jun 2008 22:44:47 +0200 -Subject: [PATCH] (_gnutls_handshake_hash_buffers_clear): Make sure deinitialized MAC hashes are initialized. - Report and tiny patch from Tomas Mraz <[EMAIL PROTECTED]>. - ---- - lib/gnutls_handshake.c | 3 ++- - 1 files changed, 2 insertions(+), 1 deletions(-) - -diff --git a/lib/gnutls_handshake.c b/lib/gnutls_handshake.c -index d798180..0192c9f 100644 ---- a/lib/gnutls_handshake.c -+++ b/lib/gnutls_handshake.c -@@ -68,13 +68,14 @@ - - /* Clears the handshake hash buffers and handles. - */ --inline static void -+static void - _gnutls_handshake_hash_buffers_clear (gnutls_session_t session) - { - _gnutls_hash_deinit (session->internals.handshake_mac_handle_md5, NULL); - _gnutls_hash_deinit (session->internals.handshake_mac_handle_sha, NULL); - session->internals.handshake_mac_handle_md5 = NULL; - session->internals.handshake_mac_handle_sha = NULL; -+ session->internals.handshake_mac_handle_init = 0; - _gnutls_handshake_buffer_clear (session); - } - --- -1.5.6 - -/Simon - -I have received a report against gnutls v2.4.0 which triggers a local -segmentation fault when any application calls gnutls_handshake() for an -already valid session. This is valid but not common usage. - -Btw, earlier stable releases before v2.4.0 are not affected. The -problem was introduced in v2.3.5 in the first @@-section of: - -http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=3aea821a6ce36bd14f2a3a41598db698d031fadc#patch5 - -How to reproduce: - -1. download ftp://ftp.gnutls.org/pub/gnutls/gnutls-2.4.0.tar.bz2 - you'll need libgpg-error/libgcrypt installed if you do not - have it already -2. build it: ./configure && make -3. download - 'http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=blob_plain;f=tests/mini.c;h=HEAD;hb=HEAD' - into tests/mini.c, - the latest code triggers the behaviour. -4. run cd tests; make mini;./mini - -Detailed analysis: - -The code ends up invoking gcry_md_write() on a handle that points to a -free()'d structure. Since the pointer has been free()'d, the pointer -could point to anything at the time when the code is invoked. An -attacker can't control where the pointer points to, but an attacker -could have sent data into a buffer that is in the victims memory. If -the pointer happens to point to the data buffer sent by the attacker, -the attacker may be able to control execution. - -Libgcrypt's code is: - -http://cvs.gnupg.org/cgi-bin/viewcvs.cgi/trunk/cipher/md.c?root=Libgcrypt&view=auto - -static void -md_write (gcry_md_hd_t a, const void *inbuf, size_t inlen) -{ - GcryDigestEntry *r; - - if (a->ctx->debug) - { - if (a->bufpos && fwrite (a->buf, a->bufpos, 1, a->ctx->debug) != 1) - BUG(); - if (inlen && fwrite (inbuf, inlen, 1, a->ctx->debug) != 1) - BUG(); - } - - for (r = a->ctx->list; r; r = r->next) - { - if (a->bufpos) - (*r->digest->write) (&r->context.c, a->buf, a->bufpos); - (*r->digest->write) (&r->context.c, inbuf, inlen); - } - a->bufpos = 0; -} - -For me, the crash happens because a->ctx is still valid but -a->ctx->debug is garbage, so it crashes in the fwrite, writing to a bad -file descriptor. - -Given that the code de-reference a->ctx->list or a->buf early, which is -typically garbage, normally the code will crash before using any of the -inbuf/inlen data. - -The inbuf/inlen data is normally not under attacker control, it is -generated by the local implementation to be a TLS handshake packet. -However, some elements of the TLS handshake packets may have been -influenced by the other side during the first handshake, so the -conservative approach would be to treat it as tainted. - -To turn this into an exploit, I believe the attacker needs to cause some -specific data to be located where the free()'d pointer 'a' points. To -do this reliable, you need to predict where the 'a' pointer will point -to and to put some custom data at that memory address. Once that is -done, you could make the first fwrite() in the function above write some -data to an already open file descriptor. Of course, the attacker needs -to know the address of the file descriptor, and make that address be -part of the data sent to to the victim. - -However, causing custom data to be placed at the point where an earlier -free()'d pointer points to appears difficult to do on normal platforms -where you typically don't know the heap memory addresses. _______________________________________________ Frugalware-git mailing list [email protected] http://frugalware.org/mailman/listinfo/frugalware-git
