[FYI] (Fwd) Serious bug in PGP - versions 5 and 6

["Axel H Horns" <horns@ipjur.com>]

------- Forwarded message follows -------
To:             	ukcrypto@maillist.ox.ac.uk
Subject:        	Serious bug in PGP - versions 5 and 6 
Date sent:      	Thu, 24 Aug 2000 08:09:07 +0100
From:           	Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
Send reply to:  	ukcrypto@maillist.ox.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.



------- End of forwarded message -------