mirror of
git://git.gnupg.org/gnupg.git
synced 2024-12-23 10:29:58 +01:00
126 lines
4.5 KiB
Plaintext
126 lines
4.5 KiB
Plaintext
|
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 .
|