doc/vuln-announce-cve-2006-6235.txt

   1      GnuPG: remotely controllable function pointer [CVE-2006-6235]
   2     ===============================================================
   3                               2006-12-04
   4
   5 Summary
   6 =======
   7
   8 Tavis Ormandy of the Gentoo security team identified a severe and
   9 exploitable bug in the processing of encrypted packets in GnuPG.
  10
  11 [ Please do not send private mail in response to this message.  The
  12   mailing list gnupg-devel is the best place to discuss this problem
  13   (please subscribe first so you don't need moderator approval [1]). ]
  14
  15
  16 Impact
  17 ======
  18
  19 Using malformed OpenPGP packets an attacker is able to modify and
  20 dereference a function pointer in GnuPG.  This is a remotely
  21 exploitable bug and affects any use of GnuPG where an attacker can
  22 control the data processed by GnuPG.  It is not necessary limited to
  23 encrypted data, also signed data may be affected.
  24
  25 Affected versions: All versions of GnuPG   < 1.4.6
  26                    All versions of GnuPG-2 < 2.0.2
  27                    All beta versions of GnuPG-2 (1.9.0 .. 1.9.95)
  28 Affected tools: gpg, gpgv, gpg2 and gpgv2.
  29 Affected platforms: All.
  30
  31 gpg-agent, gpgsm as well as other tools are not affected.
  32
  33 A workaround is not known.
  34
  35
  36 Solution
  37 ========
  38
  39 If you are using a vendor supplied version of GnuPG:
  40
  41  * Wait for an update from your vendor.  Vendors have been informed on
  42    Saturday December 2, less than a day after this bug has been reported.
  43
  44 If you are using GnuPG 1.4:
  45
  46  * Update as soon as possible to GnuPG 1.4.6. It has been uploaded to
  47    the usual location: ftp://ftp.gnupg.org/gcrypt/gnupg/.  This version
  48    was due to be released anyway this week.  See
  49    http://www.gnupg.org/download/ for details.
  50
  51  * Or: As another and less intrusive option, apply the attached patch
  52    to GnuPG 1.4.5.  This is the smallest possible fix.
  53
  54 If you are using GnuPG 2.0:
  55
  56  * Apply the attached patch against GnuPG 2.0.1.
  57
  58  * Or: Stop using gpg2 and gpgv2, install GnuPG 1.4.6 and use gpg and gpgv
  59    instead.
  60
  61 If you are using a binary Windows version of GnuPG:
  62
  63  * A binary version of GnuPG 1.4.6 for Windows is available as usual.
  64
  65  * Gpg4win 1.0.8, including GnuPG 1.4.6, is available.  Please go to
  66    http://www.gpg4win.org .
  67
  68
  69
  70
  71 Background
  72 ==========
  73
  74 GnuPG uses data structures called filters to process OpenPGP messages.
  75 These filters ware used in a similar way as a pipelines in the shell.
  76 For communication between these filters context structures are used.
  77 These are usually allocated on the stack and passed to the filter
  78 functions.  At most places the OpenPGP data stream fed into these
  79 filters is closed before the context structure gets deallocated.
  80 While decrypting encrypted packets, this may not happen in all cases
  81 and the filter may use a void contest structure filled with garbage.
  82 An attacker may control this garbage.  The filter context includes
  83 another context used by the low-level decryption to access the
  84 decryption algorithm.  This is done using a function pointer.  By
  85 carefully crafting an OpenPGP message, an attacker may control this
  86 function pointer and call an arbitrary function of the process.
  87 Obviously an exploit needs to prepared for a specific version,
  88 compiler, libc, etc to be successful - but it is definitely doable.
  89
  90 Fixing this is obvious: We need to allocate the context on the heap
  91 and use a reference count to keep it valid as long as either the
  92 controlling code or the filter code needs it.
  93
  94 We have checked all other usages of such a stack based filter contexts
  95 but fortunately found no other vulnerable places.  This allows to
  96 release a relatively small patch.  However, for reasons of code
  97 cleanness and easier audits we will soon start to change all these
  98 stack based filter contexts to heap based ones.
  99
 100
 101 Support
 102 =======
 103
 104 g10 Code GmbH, a Duesseldorf based company owned and headed by GnuPG's
 105 principal author, is currently funding GnuPG development.  As evident
 106 by the two vulnerabilities found within a week, a review of the entire
 107 code base should be undertaken as soon as possible.  As maintainers we
 108 try to do our best and are working slowly through the code.  The long
 109 standing plan is to scrutinize the 2.0 code base, write more test
 110 cases and to backport new fixes and cleanups to 1.4.  However, as a
 111 small company our resources are limited and we need to prioritize
 112 other projects which get us actual revenues.  Support contracts or
 113 other financial backing would greatly help us to improve the quality
 114 of GnuPG.
 115
 116
 117 Thanks
 118 ======
 119
 120 Tavis Ormandy found this vulnerability.
 121
 122
 123
 124
 125 [1] See http://lists.gnupg.org/mailman/listinfo/gnupg-devel .