[LWN Logo]
[Timeline]
Date: Thu, 24 Aug 2000 23:15:39 -0400 (EDT)
From: CERT Advisory <cert-advisory@cert.org>
To: cert-advisory@cert.org
Subject: CERT Advisory CA-2000-18


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

CERT Advisory CA-2000-18 PGP May Encrypt Data With Unauthorized ADKs

   Original release date: August 24, 2000
   Last revised: --
   Source: CERT/CC
   
   A complete revision history is at the end of this file.
   
Systems Affected

     * PGP versions 5.5.x through 6.5.3, domestic and international
       
Overview

   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.
   
   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.
   
   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.
   
I. Description

   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
   
   [25]http://senderek.de/security/key-experiments.html
          
   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".
   
   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.
   
   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.
   
   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.
   
   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.
   
   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.
   
II. Impact

   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.
   
   For this vulnerability to be exploited, the following conditions must
   hold
     * the sender must be using a vulnerable version of PGP
     * the send must be encrypting data with a certificate modified by
       the attacker
     * the sender must acknowledge a warning dialog that an ADK is
       associated with the certificate
     * the sender have the key for the bogus ADK already on their local
       keyring
     * the bogus ADK must be signed certificate by a CA that the sender
       trusts
     * the attacker be able to obtain the ciphertext sent from the sender
       to the victim
       
   Taken together, these factors limit reasonable exploitation of this
   vulnerability to those situations in which the key identified as the
   ADK is known valid key. This might occur when the attacker is an
   insider known to the victim, but is unlikely to occur if the attacker
   is a completely unrelated third party.
   
   Viewing the keys in a GUI interface clearly shows that an ADK is
   associated with a given recipient, as shown in this [26]image.
   
   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.
   
   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.
   
III. Solution

Apply a patch

   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.
   
   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.
   
Check certificates for ADKs before adding them to a keyring.

   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.
   
   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.
   
   Users of GnuPG can test for certificates with ADKs by running the
   command
   
   gpg --list-packet
          
   Certificates with legitimate ADKs will contain in the output
   
   hashed subpkt 10 len 23 (additional recipient request)
          
   while those missing the "hashed" keyword
   
   subpkt 10 len 23 (additional recipient request)
          
   appear to indicate maliciously modified certificates.
   
Make a reliable copy of your public certificate publicly available.

   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.
   
   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.
   
   For example, the CERT/CC PGP certificate does NOT contain any ADKs,
   and a legitimate version can be obtained for our SSL secured web site
   at
   
   [27]https://www.cert.org/pgp/cert_pgp_key.asc
          
   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.
   
Appendix A. Vendor Information

Network Associates, Inc.

   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.
   
   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.
   
   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.
   
   We will have new information as soon as it becomes available at
   http://www.pgp.com.
   
   Philip Zimmermann
   prz@pgp.com
   19:00 PDT Thursday 24 Aug 2000
   
   A signed version of this statement is available at
   
   [28]CA-2000-18/pgp.asc
     _________________________________________________________________
   
   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.
     _________________________________________________________________
   
   Authors: Cory Cohen, Shawn Hernan, Jeff Havrilla, and Jeff Lanza.
   Graphics developed by Matt DeSantis. [29]Feedback on this advisory is
   appreciated.
   ______________________________________________________________________
   
   This document is available from:
   [30]http://www.cert.org/advisories/CA-2000-18.html
   ______________________________________________________________________
   
CERT/CC Contact Information

   Email: [31]cert@cert.org
          Phone: +1 412-268-7090 (24-hour hotline)
          Fax: +1 412-268-6989
          Postal address:
          CERT Coordination Center
          Software Engineering Institute
          Carnegie Mellon University
          Pittsburgh PA 15213-3890
          U.S.A.
          
   CERT personnel answer the hotline 08:00-20:00 EST(GMT-5) / EDT(GMT-4)
   Monday through Friday; they are on call for emergencies during other
   hours, on U.S. holidays, and on weekends.
   
Using encryption

   We strongly urge you to encrypt sensitive information sent by email.
   Our public PGP key is available from
   
   [32]http://www.cert.org/CERT_PGP.key
       
   If you prefer to use DES, please call the CERT hotline for more
   information.
   
Getting security information

   CERT publications and other security information are available from
   our web site
   
   [33]http://www.cert.org/
       
   To be added to our mailing list for advisories and bulletins, send
   email to [34]cert-advisory-request@cert.org and include SUBSCRIBE
   your-email-address in the subject of your message.
   
   * "CERT" and "CERT Coordination Center" are registered in the U.S.
   Patent and Trademark Office.
   ______________________________________________________________________
   
   NO WARRANTY
   Any material furnished by Carnegie Mellon University and the Software
   Engineering Institute is furnished on an "as is" basis. Carnegie
   Mellon University makes no warranties of any kind, either expressed or
   implied as to any matter including, but not limited to, warranty of
   fitness for a particular purpose or merchantability, exclusivity or
   results obtained from use of the material. Carnegie Mellon University
   does not make any warranty of any kind with respect to freedom from
   patent, trademark, or copyright infringement.
     _________________________________________________________________
   
   [35]Conditions for use, disclaimers, and sponsorship information
   
   Copyright 2000 Carnegie Mellon University.
   
   Revision History
August 24, 2000:  Initial release

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBOaXiNFr9kb5qlZHQEQI2ogCg2V08c7bQJ4nZ81g5dhYISgzD474An1yi
b91OtEGlUFkU9y5S0oe6AMmc
=xnhH
-----END PGP SIGNATURE-----