Skip to content

Commit 861d7d0

Browse files
committed
1 parent 0173cd5 commit 861d7d0

File tree

1 file changed

+125
-0
lines changed

1 file changed

+125
-0
lines changed

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

+125
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,125 @@
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 .

0 commit comments

Comments
 (0)