[svn] GnuPG - r4369 - trunk/doc

[svn author wk]

Author: wk
Date: 2006-12-06 17:38:34 +0100 (Wed, 06 Dec 2006)
New Revision: 4369

Added:
   trunk/doc/vuln-announce-cve-2006-6235.txt
Log:


Added: trunk/doc/vuln-announce-cve-2006-6235.txt
===================================================================
--- trunk/doc/vuln-announce-cve-2006-6235.txt	2006-12-06 10:48:55 UTC (rev 4368)
+++ trunk/doc/vuln-announce-cve-2006-6235.txt	2006-12-06 16:38:34 UTC (rev 4369)
@@ -0,0 +1,125 @@
+     GnuPG: remotely controllable function pointer [CVE-2006-6235]
+    ===============================================================
+                              2006-12-04
+
+Summary
+=======
+
+Tavis Ormandy of the Gentoo security team identified a severe and
+exploitable bug in the processing of encrypted packets in GnuPG.
+
+[ Please do not send private mail in response to this message.  The
+  mailing list gnupg-devel is the best place to discuss this problem
+  (please subscribe first so you don't need moderator approval [1]). ]
+
+
+Impact
+======
+
+Using malformed OpenPGP packets an attacker is able to modify and
+dereference a function pointer in GnuPG.  This is a remotely
+exploitable bug and affects any use of GnuPG where an attacker can
+control the data processed by GnuPG.  It is not necessary limited to
+encrypted data, also signed data may be affected.
+
+Affected versions: All versions of GnuPG   < 1.4.6 
+                   All versions of GnuPG-2 < 2.0.2
+                   All beta versions of GnuPG-2 (1.9.0 .. 1.9.95)
+Affected tools: gpg, gpgv, gpg2 and gpgv2.
+Affected platforms: All.
+
+gpg-agent, gpgsm as well as other tools are not affected.
+
+A workaround is not known. 
+
+
+Solution
+========
+
+If you are using a vendor supplied version of GnuPG:
+
+ * Wait for an update from your vendor.  Vendors have been informed on
+   Saturday December 2, less than a day after this bug has been reported.
+
+If you are using GnuPG 1.4: 
+
+ * Update as soon as possible to GnuPG 1.4.6. It has been uploaded to
+   the usual location: ftp://ftp.gnupg.org/gcrypt/gnupg/.  This version
+   was due to be released anyway this week.  See
+   http://www.gnupg.org/download/ for details.
+
+ * Or: As another and less intrusive option, apply the attached patch
+   to GnuPG 1.4.5.  This is the smallest possible fix.
+
+If you are using GnuPG 2.0:
+
+ * Apply the attached patch against GnuPG 2.0.1.
+
+ * Or: Stop using gpg2 and gpgv2, install GnuPG 1.4.6 and use gpg and gpgv
+   instead.
+
+If you are using a binary Windows version of GnuPG:
+
+ * A binary version of GnuPG 1.4.6 for Windows is available as usual.
+
+ * Gpg4win 1.0.8, including GnuPG 1.4.6, is available.  Please go to
+   http://www.gpg4win.org .
+
+
+
+
+Background
+==========
+
+GnuPG uses data structures called filters to process OpenPGP messages.
+These filters ware used in a similar way as a pipelines in the shell.
+For communication between these filters context structures are used.
+These are usually allocated on the stack and passed to the filter
+functions.  At most places the OpenPGP data stream fed into these
+filters is closed before the context structure gets deallocated.
+While decrypting encrypted packets, this may not happen in all cases
+and the filter may use a void contest structure filled with garbage.
+An attacker may control this garbage.  The filter context includes
+another context used by the low-level decryption to access the
+decryption algorithm.  This is done using a function pointer.  By
+carefully crafting an OpenPGP message, an attacker may control this
+function pointer and call an arbitrary function of the process.
+Obviously an exploit needs to prepared for a specific version,
+compiler, libc, etc to be successful - but it is definitely doable.
+
+Fixing this is obvious: We need to allocate the context on the heap
+and use a reference count to keep it valid as long as either the
+controlling code or the filter code needs it.
+
+We have checked all other usages of such a stack based filter contexts
+but fortunately found no other vulnerable places.  This allows to
+release a relatively small patch.  However, for reasons of code
+cleanness and easier audits we will soon start to change all these
+stack based filter contexts to heap based ones.
+
+
+Support 
+=======
+
+g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's
+principal author, is currently funding GnuPG development.  As evident
+by the two vulnerabilities found within a week, a review of the entire
+code base should be undertaken as soon as possible.  As maintainers we
+try to do our best and are working slowly through the code.  The long
+standing plan is to scrutinize the 2.0 code base, write more test
+cases and to backport new fixes and cleanups to 1.4.  However, as a
+small company our resources are limited and we need to prioritize
+other projects which get us actual revenues.  Support contracts or
+other financial backing would greatly help us to improve the quality
+of GnuPG.
+
+
+Thanks
+======
+
+Tavis Ormandy found this vulnerability.
+
+
+
+
+[1] See http://lists.gnupg.org/mailman/listinfo/gnupg-devel .