Original release date: August 24, 2000<BR>
Last revised: September 28, 2000<BR>
Source: CERT/CC<BR>
<P>A complete revision history is at the end of this file.
<A NAME="affected">
<H3>Systems Affected</H3>
<UL>
<LI>PGP versions 5.5.x through 6.5.3, domestic and international</LI>
</UL>
<A NAME="overview">
<H2>Overview</H2>
<P>Additional Decryption Keys (ADKs) is a feature introduced into PGP
(Pretty Good Privacy) versions 5.5.x through 6.5.3 that allows
authorized extra decryption keys to be added to a user's public key
certificate. However, an implementation flaw in PGP allows unsigned
ADKs which have been maliciously added to a certificate to be used for
encryption.
<P>Data encrypted with PGP 5.5.x through 6.5.3 using a modified
certificate will generate ciphertext encrypted with the ADK subject to
the conditions list in the impact section. The attacker who modified
the certificate can obtain the plaintext from this ciphertext.
<P>PGP does not correctly detect this form of certificate modification
because it fails to check if the ADK is stored in the signed (hashed)
portion of the public certificate. As a result, normal methods for
evaluating the legitimacy of a public certificate (fingerprint
verification) are not sufficient for users of vulnerable versions of
PGP.
<A NAME="description">
<H2>I. Description</H2>
<P>A serious problem in the handling of certificates when encrypting
with PGP versions 5.5.x through 6.5.3 has recently been discovered by Ralf
Senderek. A detailed description of his research and conclusions can
be found at
<DL><DD>
<A HREF="http://senderek.de/security/key-experiments.html">
http://senderek.de/security/key-experiments.html</A>
</DL>
<P>This advisory refers to "PGP certificates", which most users would
refer to as a "PGP keys". PGP certificates are the files used to
store and exchange keys. A certificate contains one or more keys, as
well as other information such as the creation time, signatures by
other keys, and "additional decryption keys".
<P>An Additional Decryption Key (ADK) is a mechanism by which a second
decryption key can be associated with a user's primary key in a
certificate. All data encrypted for the primary key would also be
encrypted with the second key. This configuration might be used, for
example, in environments where data encrypted with an individual's key
also needs to be available to their employer.
<P>The ADK feature is intended to only be available on those
certificates where the user specifically consented to having an
additional key associated with theirs. However, because of an
implementation flaw in some versions of PGP, ADKs added to a victim's
certificate by an attacker may be used for encryption in addition to
the victim's key without their consent.
<P>Since a user's public key certificate is often widely distributed,
an attacker could make this modification to a specific copy of the
certificate without the legitimate user's knowledge. When a
vulnerable version of PGP uses the modified certificate for
encryption, it fails to detect that the ADK is contained in the
unsigned portion of the certificate. Because PGP does not report an
invalid signature, senders using the modified certificate have no way
to detect the modification without complicated manual inspection.
<P>
<TABLE>
<TR>
<TD><IMG SRC="CA-2000-18/fig1.gif"
ALT="A public key certificate with a legitimate ADK"></TD>
<TD><IMG SRC="CA-2000-18/fig2.gif"
ALT="A modified public key certificate with a malicious ADK"></TD>
</TR>
<TR>
<TD><IMG SRC="CA-2000-18/legend.gif" ALT="A legend for the figures"></TD>
</TR>
</TABLE>
<P>No legitimately produced PGP certificate will exhibit this
vulnerability, nor is this an inherent weakness in the ADK
functionality. Your exposure to this vulnerability is independent of
whether or not you legitimately employ ADKs.
<P>The PGP Software Development Kit (PGP SDK) has this vulnerability,
implying that PGP plugins and other PGP enabled applications may be
vulnerable as well. We will provide additional information as it
becomes available.
<A NAME="impact">
<H2>II. Impact</H2>
<P>Attackers who are able to modify a victim's public certificate may
be able to recover the plaintext of any ciphertext sent to the victim
using the modified certificate.
<P>For this vulnerability to be exploited, the following conditions
must hold:
<UL>
<LI>the sender must be using a vulnerable version of PGP
<LI>the sender must be encrypting data with a certificate modified by the attacker
<LI>the sender must acknowledge a warning dialog that an ADK is associated with the certificate
<LI>the sender must already have the key for the bogus ADK on their local keyring
<LI>the bogus ADK must be a certificate signed by a CA that the sender trusts
<LI>the attacker must be able to obtain the ciphertext sent from the sender to the victim
</UL>
<P>Taken together, these conditions limit the likely exploitation of
this vulnerability to those situations in which the key identified as
the ADK is a known valid key. These conditions might occur when the
attacker is an insider known to the victim, but are unlikely to occur
if the attacker is a completely unrelated third party.
<P>Viewing the keys in a GUI interface clearly shows that an ADK is
associated with a given recipient, as shown in this <A
HREF="CA-2000-18/ADK.gif">image</A>.
<P>Since the key associated with the ADK is clearly listed as one of
the recipients of the ciphertext, it is likely that the sender might
notice this and be able to identify the attacker.
<P>The recipient may use any type of PGP key, including RSA and
Diffie-Hellman. The version of PGP used by the recipient has no
impact on the attack.
<A NAME="solution">
<H2>III. Solution</H2>
<H4>Apply a patch</H4>
<P>Network Associates has produced a new version of PGP 6.5 which
corrects this vulnerability by requiring that the ADK be included in
the signed portion of the certificate.
<P>Appendix A contains information provided by vendors for this
advisory. We will update the appendix as we receive more information.
If you do not see your vendor's name, the CERT/CC did not hear from
that vendor. Please contact your vendor directly.</P>
<H4>Check certificates for ADKs before adding them to a keyring.</H4>
<P>Users of PGP who want to ensure that they are not using a modified
certificate should check for the existence of ADKs when adding new
keys to their keyring. Certificates that do not have ADKs are not
vulnerable to this problem. Certificates which do have ADKs may be
legitimate or modified and should be confirmed using an out-of-band
communication.
<P>Users of PGP 6.x for Windows and MacOS can test for the presence of
ADKs in a certificate by right clicking on the certificate and
selecting "Key Properties". If the ADK tab is present, the key has
one or more ADKs and might be a malicious certificate. We are not
aware of a way to identify ADKs in the UNIX command line version of
PGP 5.x or 6.x.
<P>Users of GnuPG can test for certificates with ADKs by running the
command
<DL><DD>
gpg --list-packet <suspect key file>
</DL>
<P>Certificates with legitimate ADKs will contain in the output
<DL><DD>
hashed subpkt 10 len 23 (additional recipient request)
</DL>
while those missing the "hashed" keyword
<DL><DD>
subpkt 10 len 23 (additional recipient request)
</DL>
appear to indicate maliciously modified certificates.
<H4>Make a reliable copy of your public certificate publicly
available.</H4>
<P>Since the recipient of messages encrypted with a modified
certificate cannot prevent the plaintext from being recovered by the
attacker, their best course of action is to ensure that senders are
able to easily obtain legitimate copies of their public certificate.
<P>Until this problem has been widely corrected, you may wish to make
your legitimate certificate available in a location that is strongly
authenticated using a different technology, or to make it available in
more than one place.
<P>For example, the CERT/CC PGP certificate does <B>NOT</B> contain
any ADKs, and a legitimate version can be obtained from our SSL secured
web site at
<DL><DD>
<A HREF="https://www.cert.org/pgp/cert_pgp_key.asc">
https://www.cert.org/pgp/cert_pgp_key.asc</A>
</DL>
<P>You may also want to check that your public certificate has not
been modified on the public certificate servers. Changes are likely
to be made to the popular PGP certificate servers to detect and reject
invalid certificates that attempt to exploit this vulnerability.
<A NAME="vendors">
<H2>Appendix A. Vendor Information</H2>
<A NAME="gpg">
<H4>GNU Privacy Guard</H4>
<p>GNUPG does not support ADKs, and is not vulnerable to this problem.
<A NAME="nai">
<H4>Network Associates, Inc.</H4>
<P>We at NAI/PGP Security regret this important bug in the ADK feature
that has been described on various Internet postings today (Thursday
24 Aug). We were made aware of this bug in PGP early this morning.
<P>We are responding as fast as we can, and expect to have new 6.5.x
releases out to fix this bug late Thursday evening. The MIT web
site should have a new PGP 6.5.x freeware release early Friday, and
the NAI/PGP web site should have patches out for the commercial
releases at about the same time. As of this afternoon (Thursday),
the PGP key server at PGP already filters out keys with the bogus
ADK packets. We expect to have fixes available for the other key
servers that run our software by tomorrow. We have also alerted
the other vendors that make PGP key server software to the problem,
and expect Highware/Veridis in Belgium to have their key servers
filtering keys the same way by Friday.
<P>The fixes that we are releasing for the PGP client software
filters out the offending ADK packets. We already warn the users
whenever they are about to use an ADK, even in the normal case.
<P>We will have new information as soon as it becomes available at
http://www.pgp.com.
<P>Philip Zimmermann<br>
prz@pgp.com<br>
19:00 PDT Thursday 24 Aug 2000<br>
<P>A signed version of this statement is available at
<DL><DD>
<A HREF="CA-2000-18/pgp.asc">
CA-2000-18/pgp.asc</A>
</DL>
<HR NOSHADE>
<P>The CERT Coordination Center thanks Ralf Senderek for bringing this
problem to light and Network Associates for developing a solution and
assisting in the preparation of this advisory.
<HR NOSHADE>
<P>Authors: Cory Cohen, Shawn Hernan, Jeff Havrilla, and Jeffrey P. Lanza.
Graphics developed by Matt DeSantis.
<A HREF="mailto:cert@cert.org?subject=CA-2000-18%20Feedback%20VU747124">
Feedback</A> on this advisory is appreciated.
<P></P>
<!--#include virtual="/include/footer_nocopyright.html" -->
<P>Copyright 2000 Carnegie Mellon University.</P>
<P>Revision History
<PRE>
August 24, 2000: Initial release
August 25, 2000: Fixed some typographical and semantic errors in the Impact section.
August 29, 2000: Added information about the GNU Privacy Guard, GPG
September 28, 2000: Corrected misspelled name in author section
</PRE>
|