Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 156947 - app-crypt/gnupg: exploitable invalid memory references [CVE-2006-6235]
Summary: app-crypt/gnupg: exploitable invalid memory references [CVE-2006-6235]
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: http://article.gmane.org/gmane.comp.e...
Whiteboard: B2? [glsa]
Keywords:
: 157340 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-12-02 14:37 UTC by Tavis Ormandy (RETIRED)
Modified: 2007-02-11 10:24 UTC (History)
4 users (show)

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


Attachments
patch against 1.4.x branch from werner koch (filter-context-14-small.diff,6.02 KB, patch)
2006-12-04 07:07 UTC, Tavis Ormandy (RETIRED)
no flags Details | Diff
patch against 1.4.x branch from werner koch (filter-context-14-small.diff,6.02 KB, patch)
2006-12-04 07:30 UTC, Tavis Ormandy (RETIRED)
no flags Details | Diff
patch against 1.9.x branch from werner koch (filter-context-20-small.diff,7.33 KB, patch)
2006-12-04 07:40 UTC, Tavis Ormandy (RETIRED)
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tavis Ormandy (RETIRED) gentoo-dev 2006-12-02 14:37:43 UTC
gnupg may reference a stack buffer after it's containing stack frame has been unwound, the structure contains function pointers that are dereferenced, and its contents can be controlled by getting gpg to call various functions that have automatic variables that can be controlled.
Comment 1 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-04 07:07:58 UTC
Created attachment 103325 [details, diff]
patch against 1.4.x branch from werner koch
Comment 2 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-04 07:30:52 UTC
Created attachment 103327 [details, diff]
patch against 1.4.x branch from werner koch
Comment 3 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-04 07:40:21 UTC
Created attachment 103328 [details, diff]
patch against 1.9.x branch from werner koch
Comment 4 Matthias Geerdsen (RETIRED) gentoo-dev 2006-12-05 12:35:57 UTC
CC'ing robbat2, since he handled/s bug 156476 also

any disclosure date or anything?
Comment 5 Sune Kloppenborg Jeppesen (RETIRED) gentoo-dev 2006-12-05 22:09:38 UTC
I think this will go public some time today.
Comment 6 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-06 09:54:17 UTC
public now, the changes from the previous version should be minimal.

vorlon/robbat2: please commit when ready :)
Comment 7 Rajiv Aaron Manglani (RETIRED) gentoo-dev 2006-12-06 12:14:57 UTC
*** Bug 157340 has been marked as a duplicate of this bug. ***
Comment 8 Tavis Ormandy (RETIRED) gentoo-dev 2006-12-06 16:13:54 UTC
Okay, it looks like 1.4.6 has hit portage.

Arch teams, please test and mark stable gnupg 1.4.6, Thanks!
Comment 9 Jeroen Roovers (RETIRED) gentoo-dev 2006-12-06 19:23:02 UTC
Tested and marked for HPPA.
Comment 10 Rajiv Aaron Manglani (RETIRED) gentoo-dev 2006-12-06 20:01:43 UTC
From: 	  wk@g10code.com
Subject: 	GnuPG: remotely controllable function pointer [CVE-2006-6235]
Date: 	December 6, 2006 10:58:16 AM EST
To: 	  bugtraq@securityfocus.com
Cc: 	  lwn@lwn.net

     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 .

-- 
g10 Code GmbH       http://g10code.com      AmtsGer. Wuppertal HRB 14459
H
Comment 11 Rajiv Aaron Manglani (RETIRED) gentoo-dev 2006-12-06 20:01:43 UTC
From: 	  wk@g10code.com
Subject: 	GnuPG: remotely controllable function pointer [CVE-2006-6235]
Date: 	December 6, 2006 10:58:16 AM EST
To: 	  bugtraq@securityfocus.com
Cc: 	  lwn@lwn.net

     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 .

-- 
g10 Code GmbH       http://g10code.com      AmtsGer. Wuppertal HRB 14459
Hüttenstr. 61                               Geschäftsführung Werner Koch
D-40699 Erkrath  -=- The GnuPG Experts -=-  USt-Id DE215605608
&#65532;&#65532;
Comment 12 Jason Wever (RETIRED) gentoo-dev 2006-12-06 20:50:24 UTC
SPARC stable
Comment 13 Joshua Jackson (RETIRED) gentoo-dev 2006-12-06 21:37:43 UTC
x86 is done ^.^ 
Comment 14 Markus Rothe (RETIRED) gentoo-dev 2006-12-07 02:47:44 UTC
ppc64 stable
Comment 15 Alexander Færøy 2006-12-07 04:06:04 UTC
Stable on Alpha and MIPS.
Comment 16 Alexander Færøy 2006-12-07 04:23:21 UTC
Stable on IA64 too.
Comment 17 Tobias Scherbaum (RETIRED) gentoo-dev 2006-12-07 05:49:39 UTC
ppc stable
Comment 18 Daniel Gryniewicz (RETIRED) gentoo-dev 2006-12-08 12:46:00 UTC
amd64 done.
Comment 19 Raphael Marichez (Falco) (RETIRED) gentoo-dev 2006-12-10 05:39:03 UTC
GLSA 200612-03
Comment 20 David Li 2006-12-30 17:04:59 UTC
Is 2.0.1-r1 supposed to be slot 0? This seems to break dependencies for packages like seahorse that has a dependency like "=app-crypt/gnupg-1.4*"

One of them seems to be wrong.