FITUG e.V.

Förderverein Informationstechnik und Gesellschaft

Serious bug in PGP - versions 5 and 6

------- 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 -------

Zurück