[ale] Fw: CERT Advisory CA-2000-18
Frank Zamenski
fzamenski at voyager.net
Fri Aug 25 04:11:47 EDT 2000
FYI.
>
> -----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 at 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 at 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 at 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-----
>
--
To unsubscribe: mail majordomo at ale.org with "unsubscribe ale" in message body.
More information about the Ale
mailing list