|
Versiones Comprometidas
El Bug
afecta a las versiones 5.x y 6.x del PGP. La versión actual 6.5i ya
trae el parche respectivo
Por que
se produce
Las
versiones 5.x y 6.x vienen con una característica que le agrega a la
clave pública "claves de desencripción adicionales", esta
es una característica que permitiría, si el usuario así lo desea,
usar "Key Escrow" , no estoy seguro de la traducción
correcta en este caso pero a continuación explico un poco de que se
trata:
Muchos
gobiernos, a través de sus agencias de seguridad han tratado de
imponer sistemas de encriptación que puedan ser abiertos por agencias
del gobierno provistas de una orden judicial. Ese es el concepto de
Key Escrow del cual escuché por primera vez cuando se intentó
imponer la encriptación "Clipper" que dejaba una puerta
para que agencias del gobierno autorizadas pudieran desencriptar
mensajes cifrados con esa tecnología.
El asunto
es que la idea no prendió y muy poca gente se convenció que el Key
Escrow fuera algo seguro o conveniente para ellos, lo que finalmente
se impuso fue la encriptación fuerte que ni siquiera agencias del
gobierno pueden romper.
A partir
de la versión 5 y hasta la 6.5.1i (beta) PGP concedió la posibilidad
que un usuario agregara claves de desencripción adicionales a
su clave publica de manera que no solo el destinatario sino que una
tercera parte certificada pudiese también desencriptar los mensajes.
En este punto es donde se encuentra el origen del bug de PGP.
Cuando se
produce la vulnerabilidad
Para que
el problema de seguridad ocurra deben darse las siguientes
condiciones:
-
El
que envía debe estar usando una versión vulnerable del PGP
-
Debe
estar encriptando los datos con un certificado modificado por el
atacante
-
Debe
confirmar su conformidad ante la advertencia del programa sobre
una ADK (aditional decription key) se está usando en el
certificado
-
Debe
tener una clave falsa del ADK instalada en su keyring
-
La
ADK falsa debe poseer un certificado firmado por alguien en quien
confía el que envía
En suma
este bug afecta principalmente a los que usan claves adicionales de
desencripción en versiones del PGP desde 5.0 a 6.5.1i (beta) y que
poseen una de esas ADK falsificadas por el atacante instaladas en su
keyring
Para
mejor información transcribo todo el diálogo de los especialistas en
Usenet que alertaron sobre este problema:
25 August 2000: Add Ralf Senderek's important
corrections to CERT announcement.
24 August 2000
To: ukcrypto@maillist.ox.ac.uk
Subject: Serious bug in PGP - versions 5 and 6
Date: Thu, 24 Aug 2000 08:09:07 +0100
From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
Ralf Senderek has found a horrendous bug in PGP versions 5 and 6.
It's of scientific interest because it spectacularly confirms a
prediction made by a number of us in the paper on `The Risks of Key
Recovery, Key Escrow, and Trusted Third-Party Encryption'
<http://www.cdt.org/crypto/risks98/> that key escrow would make it
much more difficult than people thought to build secure systems.
He's written a paper on his work and it's at
http://senderek.de/security/key-experiments.html
Since NAI joined the Key Recovery Alliance, PGP has supported
"Additional Decryption Keys" which can be added to a public key. The
sender will then encrypt the session key to these as well as to your
main public key. The bug is that some versions of PGP respond to ADK
subpackets in the non-signed part of the public key data structure.
The effect is that GCHQ can create a tampered version of your PGP
public key containing a public key whose corresponding private key is
also known to themselves, and circulate it. People who encrypt traffic
to you will encrypt it to them too.
The problem won't go away until all vulnerable versions of PGP are
retired, since it's the sender who is responsible for encrypting to
the ADKs, not the recipient.
In the meantime there might be a nasty denial-of-service attack in
which bad guys upload tampered versions of everybody's public keys to
all the public keyrings.
Ross
> PS: my student Steve Early has trawled the PGP-6.5.1i-beta2 source
> code and found the bug:
>
> In file libs/pgpcdk/priv/keys/keys/pgpRngPub.c, I see two functions:
> one called ringKeyFindSubpacket(), which finds a subpacket from a
> self-signature packet, and ringKeyAdditionalRecipientRequestKey(),
> which uses ringKeyFindSubpacket() to search for ADK subpackets.
>
> ringKeyFindSubpacket() is declared as follows:
>
> PGPByte const *
> ringKeyFindSubpacket (RingObject *obj, RingSet const *set,
> int subpacktype, unsigned nth,
> PGPSize *plen, int *pcritical, int *phashed, PGPUInt32 *pcreation,
> unsigned *pmatches, PGPError *error);
>
> In particular, the "phashed" parameter is used to return whether the
> subpacket was in the hashed region. Now, looking at the call in
> ringKeyAdditionalRecipientRequestKey() I see this:
>
> krpdata = ringKeyFindSubpacket (obj, set,
> SIGSUB_KEY_ADDITIONAL_RECIPIENT_REQUEST, nth, &krdatalen,
> &critical, NULL, NULL, &matches, error);
>
> ...the "phashed" value isn't checked (or even asked for)!
>
>
> Fixing the bug, and generating BIG WARNINGS when ADKs are found in the
> non-hashed area, should be trivial.
From: "Brian Morrison" <bdm@fenrir.org.uk>
To: "ukcrypto@maillist.ox.ac.uk" <ukcrypto@maillist.ox.ac.uk>
Date: Thu, 24 Aug 2000 10:13:32 +0100
Subject: Re: Serious bug in PGP - versions 5 and 6
On Thu, 24 Aug 2000 08:09:07 +0100, Ross Anderson wrote:
>Ralf Senderek has found a horrendous bug in PGP versions 5 and 6.
[snip]
>
>The problem won't go away until all vulnerable versions of PGP are
>retired, since it's the sender who is responsible for encrypting to
>the ADKs, not the recipient.
The key issue from my point of view is which PGP versions exhibit this
bug. Is there a list by OS for instance? Might this exist within
products that use the PGP SDK?
If list members can point to a resource to find out, that would be very
useful.
--
Brian Morrison bdm@fenrir.demon.co.uk
do you know how far this has gone?
just how damaged have I become?
'Even Deeper' by Nine Inch Nails
Date: Thu, 24 Aug 2000 11:21:40 +0100 (BST)
From: Stephen Early <Stephen.Early@cl.cam.ac.uk>
To: ukcrypto@maillist.ox.ac.uk
Subject: Re: Serious bug in PGP - versions 5 and 6
Brian Morrison writes:
> On Thu, 24 Aug 2000 08:09:07 +0100, Ross Anderson wrote:
> >The problem won't go away until all vulnerable versions of PGP are
> >retired, since it's the sender who is responsible for encrypting to
> >the ADKs, not the recipient.
>
> The key issue from my point of view is which PGP versions exhibit this
> bug. Is there a list by OS for instance? Might this exist within
> products that use the PGP SDK?
Yes - the bug I found was within the PGP SDK from NAI.
At a guess (i.e. without finding and checking the source code to all
available versions) I would say that the bug exists in all versions of
PGP and the PGP SDK from NAI since the ADK feature was implemented.
The original paper is at
http://senderek.de/security/key-experiments.html - it is quite
detailed. I sent Ross a simple summary, which I reproduce here:
When a PGP key-pair is generated, the public key is stored in a file
as a number of typed 'packets': the key itself, a userid, etc. One of
these packets is a signature of the previous packets made with the
private key, to bind them together (so that, for example, the userid
cannot be changed).
In PGP version 3 files, it's as simple as that.
In PGP version 4 files, the signature packet contains some extra
fields: two sets of 'subpackets'. One set of subpackets is included in
the hash, and therefore cannot be tampered with. The other is not
included in the hash.
Some versions of PGP allow "Additional Decryption Keys" to be
specified for public keys. They are specified by including the
additional key identity in a subpacket in the signature. The idea is
that when you create a key pair and sign the public part, you sign the
identities of any ADKs that you want to use. This is supposed to
prevent ADKs from being specified without the consent of the holder of
the private key.
Unfortunately, some versions of PGP respond to ADK subpackets in the
non-hashed part of the signature. This is a blatant bug. They treat
them exactly as if they were hashed, i.e. they show up as ADKs in the
list of 'key properties', and messages encrypted to the public key
include packets allowing the session key to be obtained by holders of
the ADKs.
Tested versions of PGP:
PGP-2.6.3ia UNIX (not vulnerable - doesn't support V4 signatures)
PGP-5.0i UNIX (not vulnerable)
PGP-5.5.3i WINDOWS (VULNERABLE)
PGP-6.5.1i WINDOWS (VULNERABLE)
GnuPG-1.0.1 UNIX (not vulnerable)
The problem won't go away until all vulnerable versions of PGP are
retired, since it's the sender who is responsible for encrypting to
the ADKs, not the recipient.
As far as I can tell, nobody has done the experiment of uploading a
modified signature packet to a keyserver yet - will it replace the
existing signature packet, or be ignored? (Or possibly be stored in
addition, in which case more experiments need to be done: what will
various versions of PGP do if given keys with multiple
self-signatures?)
Programs like gnupg can be used to list pgp files at the packet level;
you can look to see whether messages you receive have been encrypted
to additional keys (gpg --list-packets). You can also look at public
keys and check for ADK subpackets in the non-hashed part of the
self-signature.
Steve Early
Date: Thu, 24 Aug 2000 12:45:40 +0200
From: Terje Elde <terje@elde.net>
To: pgp-users@cryptorights.org
Cc: ukcrypto@maillist.ox.ac.uk
Subject: Re: [PGP-USERS] FW: Serious bug in PGP - versions 5 and 6
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I realise you probably won't reply to this until time has been taking to
analyse things and prepare the official view on things, but I hope you don't
mind me offering my thoughts to you and the rest of the list.
* Will Price (wprice@cyphers.net) [000824 12:28]:
> We are looking into this and should have a response sometime
> Thursday.
Why so long? It should be easy to get this verified, and this IS of the
magnitude that you wake up whoever it takes should it be true.
> My immediate reaction if I assume that the analysis is correct is to
> recall that all of our GUI clients which support ADKs also warn the
> sender by default before ever using an ADK. So, if such an attack
> were to be performed on a key and someone obtained such a key and
> tried to encrypt to that key, a warning will appear requiring the
> sender to confirm whether they want to encrypt to the ADK or not.
> This makes such an attack a daring attack which is likely to be
> revealed rapidly and thus not a good target.
Warning about ADK's is a bad idea for several reasons. In normal situations,
neither the sender nor the recipient want this, and thanks to this error,
it'll turn up a whole host of false positives and confusion.
Not to mention that *this does not fix the problem*.
I can't see how any action can be taken except for making sure only signed
ADK's will be used, and alerting every single customer in the database.
Terje
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE5pPzS8HLgLrwmRg0RAkQAAJ9w4d+poiaPf1F8w6/395MXWsUGYgCeKZsS
sVC8Xp0E8qvN3GPCtnWZU+8=
=NOq4
-----END PGP SIGNATURE-----
Date: Thu, 24 Aug 2000 12:37:04 +0100
From: Pete Chown <Pete.Chown@skygate.co.uk>
To: ukcrypto@maillist.ox.ac.uk
Subject: Re: Serious bug in PGP - versions 5 and 6
Ross Anderson wrote:
> The effect is that GCHQ can create a tampered version of your PGP
> public key containing a public key whose corresponding private key is
> also known to themselves, and circulate it.
Has anyone investigated the keys available on the key servers to see
if anyone has done this? It would be interesting to know if anyone
knew about this bug before it became public knowledge...
--
Pete
Date: Thu, 24 Aug 2000 10:24:48 -0500
From: Adam Back <adam@cypherspace.org>
To: Ross.Anderson@cl.cam.ac.uk
Cc: ukcrypto@maillist.ox.ac.uk
Cc: ietf-openpgp@imc.org
Ross Anderson writes on uk-crypto:
> Ralf Senderek has found a horrendous bug in PGP versions 5 and 6.
>
> [...]
>
> He's written a paper on his work and it's at
>
> http://senderek.de/security/key-experiments.html
>
> Since NAI joined the Key Recovery Alliance, PGP has supported
> "Additional Decryption Keys" which can be added to a public key.
>
> The sender will then encrypt the session key to these as well as to
> your main public key. The bug is that some versions of PGP respond
> to ADK subpackets in the non-signed part of the public key data
> structure. The effect is that GCHQ can create a tampered version of
> your PGP public key containing a public key whose corresponding
> private key is also known to themselves, and circulate it. People
> who encrypt traffic to you will encrypt it to them too.
Amazing, and really unfortunate. Those of us who invested large
amounts of effort in ensuring the ADK subpackets were not included in
the ietf openPGP standard can be pleased we succeeded -- otherwise
gnuPG and other implementations may now also have contributed to this
risk. As it is gnuPG doesn't honor ADK requests, and all the rfc2440
says about them is:
10 = placeholder for backward compatibility
At the time I was suggesting that if PGP really must insist on
creating software to escrow communications (the primary argument being
that people didn't want to lose access to the stored mail as opposed
to being able to have designated third parties snooping mail in
transit) they should use storage key escrow.
My main premise was that communication key escrow is too risky because
an outside attacker gets the plaintext:
http://www.cypherspace.org/~adam/cdr/
"Keys used to encrypt email which is transmitted over the Internet are
more valuable to an attacker than keys used to encrypt stored files
because of the relative ease with which an attacker can obtain copies
of emailed ciphertext. Stored encrypted files in contrast are
protected by all the physical security systems the company is relying
on to protect it's paper files, plaintext data stored on disks, and
backup tapes. [...]"
There was also lots of political discussion of how unwise it was for
PGP to create a escrow infrastructure which could as easily be used by
governments as by SEC companies to archive their employees
communications.
And people quoting Phil Zimmermann a few years earlier complaining
about ViaCrypt's PGP4 for business variant which had "escrow" in the
form of a third party "encrypt-to-self" config file setting.
And I believe I recall the NSA or some other US government body
picking up on the CMR / ADK mechanism and holding it up as evidence
against the claim that key recover was complex ... "see PGP did it,
this works".
> It's of scientific interest because it spectacularly confirms a
> prediction made by a number of us in the paper on `The Risks of Key
> Recovery, Key Escrow, and Trusted Third-Party Encryption'
> <http://www.cdt.org/crypto/risks98/> that key escrow would make it
> much more difficult than people thought to build secure systems.
Yes. It really highlights the truth in the statement about the
new risks introduced by adding key escrow.
Adam
From: "Stefan Kelm" <kelm@secorvo.de>
Organization: Secorvo Security Consulting GmbH
To: pgp-friends-de@egroups.com
Date: Fri, 25 Aug 2000 16:14:22 +0200
CC: krypto@thur.de, Jya@pipeline.com
FYI:
------- Forwarded message follows -------
=================================================================
Date sent: Fri, 25 Aug 2000 16:07:25 +0100 (GMT)
From: Ralf Senderek <ralf@senderek.de>
To: cert@cert.org
Copies to: Stefan Kelm <kelm@secorvo.de>, moeller@cert.dfn.de,
Ross.Anderson@cl.cam.ac.uk
Subject: important corrections
-----BEGIN PGP SIGNED MESSAGE-----
Hello CERT,
I just have got your paper and at first sight there are some important
assertions in it which contradict the experimental results I have found.
[...]
No legitimately produced PGP certificate will exhibit this
###
### All certificates which contain Version-4-self-signatures do actually
### exhibit this vulnerability. i.e all Diffie-Hellman-keys because they
### have such a signature.
###
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
###
### NO : The presence of the ADK in the key ring is the only precondition,
### no involvement of CAs is neccessary. No user trust is required
### to make this work. Your statement is extremely missleading.
###
* the attacker be able to obtain the ciphertext sent from the sender
to the victim
[...]
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.
### THIS IS COMPLETELY FALSE! I have shown that any clean Key in
### Version-4-format (DH and RSA) with a Version-4-self-signature
### (always on DH-keys!) can be stuffed with any number of ADKs
### subsequently. Please read my study!. See key-B1 and key-F4
### they did not have any ADKs originally.
You should correct that.
Ralf Senderek.
*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
* Ralf Senderek <ralf@senderek.de> * What is privacy *
* http://senderek.de * without *
* Tel.: 02432-3960 Sandstr. 60 D-41849 Wassenberg * PGP-2.6.3i? *
*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBOaaLLymc/oJTgiNJAQH53wP/TMikKgOPDmNvhj9vBIkxtckLlMj8kmJM
W3mpWj/GyHpP6pavBckDseWcdnaKhCnAgbiluMtLTCqcrMTu2b0EA6v7bai3eYeL
XNamJIek+83AClFvUxY99qcSITURDK4x3T+U1OWoBLPJ5sJwm03JhsT3lJzgX3ZM
fM0QEwxof8g=
=HabJ
-----END PGP SIGNATURE-----
------- End of forwarded message -------
=================================================================
--------------------------------------------------------
PKI-Symposium, 10.-11.Oktober 2000, www.pki-symposium.de
--------------------------------------------------------
Dipl.-Inform. Stefan Kelm
Security Consultant
Secorvo Security Consulting GmbH
Albert-Nestler-Strasse 9, D-76131 Karlsruhe
Tel. +49 721 6105-461, Fax +49 721 6105-455
E-Mail kelm@secorvo.de, http://www.secorvo.de
-------------------------------------------------------
PGP Fingerprint 87AE E858 CCBC C3A2 E633 D139 B0D9 212B
|