15 September 2000: Add second message from Rich Wales.
15 September 2000
Date: Fri, 15 Sep 2000 20:42:56 +0100 (GMT) From: Ralf Senderek <ralf@senderek.de> To: ukcrypto@maillist.ox.ac.uk Subject: PGP "unhashed subpacket" problem possibly more serious (fwd) -----BEGIN PGP SIGNED MESSAGE----- Hello all, some very disturbing news had just arrived in my mailbox. I regard it as my obligation to inform you about this matter as soon as possible, because I can not say if I am able to help checking out at the moment due to time restrictions. Hope it is not *that* bad, really. 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? * *.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.*.* - ---------- Forwarded message ---------- Date: Fri, 15 Sep 2000 10:59:59 -0700 (PDT) From: Rich Wales <richw@webcom.com> To: cert@cert.org Cc: Phil Zimmermann <prz@pgp.com>, Mark McArdle <mmcardle@nai.com>, Ralf Senderek <ralf@senderek.de> Subject: PGP "unhashed subpacket" problem possibly more serious I've been studying the UNIX source code for PGP 6.5.1i, and it seems to me that the "unauthorized ADK" bug could be just one manifestation of what may in fact be a far more serious problem. As best I can tell, PGP's that implement the new (version-4) data format do not appear to care whether ANY signature subpacket is in the hashed section of the signature or not. If I'm right, the signature hashing mechanism can be bypassed completely, and ANY info in ANY version-4 signature (not just ARR/ADK info) can be easily forged by a malicious attacker. I haven't checked whether this problem was fixed in the wake of the "unauthorized ADK" flap or not. Also, I haven't tried to produce a bogus signature verifying this bug -- all I've done so far is to study the source code (for 6.5.1i, and also for 5.0). So, someone may wish to look into my report further before acting on it. Here are the details. The function that looks for subpackets -- ringKeyFindSubpacket(), in libs/pgpcdk/priv/keys/keys/pgpRngPub.c in the 6.5.1i source -- has a result parameter "phashed", a pointer to a variable which is set according to whether the subpacket being returned was located in the hashed section of the packet or not. HOWEVER . . . . The function is written in such a way that the "phashed" parameter (a pointer to where the result should go) can be NULL -- in which case the "phashed" value is simply discarded. And EVERY call to this function, everywhere throughout the code, passes NULL as the "phashed" parameter. In other words, unless I'm missing something obvious, NO part of the PGP program EVER bothers to check whether ANY signature subpacket is hashed or not. The proverbial "Mallory" could, it seems, fabricate a version-4 signature packet with anything at all in the unhashed section, and PGP would accept it without complaint. The same flaw is evident in the PGP 5.0 source (the 1997 version that was published in book form and scanned in Europe by various partici- pants in the "PGP International" group). So, it predates the ADK era. As I said, I haven't confirmed this bug by fabricating a bogus sig- nature (perhaps Ralf Senderek could try this, since I understand he already has some software tools for playing around with signatures). And, in particular, I can't say for certain whether this problem was taken care of by whatever NAI did to fix the ADK bug or not -- so it might or might not still be an issue, even for those who recently upgraded their PGP and/or key server systems. Just in general, BTW, I think it's worth observing that the use of "optional" result parameters is a questionable programming practice (with the possible exception of generic library routines, and maybe not even then). The function in this case really should have FORCED the calling code to pay attention to the returned "phashed" value, by demanding a non-NULL pointer parameter value. If that had been done, whoever wrote the calling code would (I hope) have been more likely to remember that he/she needed to confirm the security status of the data in question. Also, I'd propose that the whole concept of having an unhashed section in a PGP signature could stand to be reviewed. As far as I'm aware at the moment, the only =legitimate= unhashed subpacket type normally used in version-4 keys is "issuer key ID" (type 16), which I would think could just as easily go in the hashed section. Unless there's a truly pressing need for unhashed subpackets, maybe the feature ought to be deprecated to limit future abuse. I don't think this bug is generally known yet (at least, not in legitimate circles -- I haven't been following the hacker/cracker crowds). I tried to report it in alt.security.pgp a couple of weeks ago, but my posting somehow never made it to deja.com, so I don't know how far it went before getting dropped somewhere. For the moment, I'll consider this providential and will hold off on publicizing the matter further until it's been verified. Rich Wales richw@webcom.com http://www.webcom.com/richw/ PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED. RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBOcJ7iimc/oJTgiNJAQFoJQP9HAzIpL5cyU0DVdxSppeuCUWbyZyG42Yz nmEiYkxK+jfksbCa8fRXZRBnNBfvw9hhZ1TYP+h3YHGhSEqlDkgeV3olZm2EiPip jl3p5T0aagVbWhygfhgWT+gTN/3EnAkY/Hm/kJShu3mojVUC7AyRu7/59HCaRqCz ferB0lPT3k0= =KvFd -----END PGP SIGNATURE-----
Date: Fri, 15 Sep 2000 18:02:54 -0700 (PDT) From: Rich Wales <richw@webcom.com> To: cert@cert.org cc: Phil Zimmermann <prz@pgp.com>, Mark McArdle <mmcardle@nai.com>, Ralf Senderek <ralf@senderek.de>, Ross Anderson <Ross.Anderson@cl.cam.ac.uk>, Bruce Schneier <schneier@counterpane.com>, Michel Bouissou <michel@bouissou.net>, Stefan Kelm <kelm@secorvo.de>, moeller@cert.dfn.de, Stephen Early <Stephen.Early@cl.cam.ac.uk>, Ingmar Camphausen <ingmar@pca.dfn.de>, John Young <jya@pipeline.com> Subject: Unhashed subpacket update (CERT VU#382015) -----BEGIN PGP SIGNED MESSAGE----- Short version: The PGP "unhashed subpacket" problem I reported earlier today may not be quite as catastrophic as I first thought. Many -- possibly even most -- interesting subpacket types seem to be immune to this attack, either by design or by happenstance. The relevant code really needs to be checked carefully, though, and perhaps rewritten for greater clarity and less error-proneness. Longer version: ringSigParseSubpackets(), in libs/pgpcdk/priv/keys/keys/pgpRngPars.c (6.5.1i UNIX source), screens out certain specific types of unhashed subpacket -- such as those with expiration, revocability, trust, and primary user ID info -- as well as any subpacket with the "critical" flag set. The same function in the 5.0 source doesn't weed out as many types of unhashed subpackets -- just expiration dates and those marked as critical. So, for example, "Mallory" can't mount a denial-of-service attack by adding an unhashed "expiration date" subpacket to a key. I tried doing this myself, on a test key, using Ralf Senderek's "key editor" program, but it had no effect; the spurious subpacket was ignored -- albeit without any error message. I also tried to disable compression by adding an unhashed "preferred compression algorithms" subpacket to a key. This was also fruitless, but for a different reason: it appears that PGP (at least as of ver- sion 6.5.1i) simply doesn't implement this particular subpacket type. Finally, I tried to mess with the creation date of a key, by adding an unhashed "signature creation time" subpacket. But this didn't work either -- apparently because PGP only looks at the first time stamp (namely, the one already inserted into the hashed section of the self- signature). No error message resulted, though; the extra subpacket was silently ignored. I considered fabricating an unhashed "revocation key" subpacket, but haven't tried this yet. At first, it looked like this subpacket type wasn't protected (which could have allowed a nasty denial-of-service attack). However, on closer examination of the 6.5.1i code, it appears that pgpMakeSigSubs(), in libs/pgpcdk/priv/keys/pubkey/pgpMakeSig.c, has a test which may suffice to block unhashed subpackets of this type. The 6.5.1i code for validating subpackets seems haphazard to me. If I were (re)writing ringSigParseSubpackets(), I would probably ban all unhashed subpackets EXCEPT for a specified (and presumably short) list of types which were definitely acceptable in the unhashed area, rather than weed out specific subpacket types, allow all others to go through by default, and depend on additional tests elsewhere in the program. If this had been done way back in version 5.0, then I suspect the ADK bug would never have occurred, because it would have required whoever added the new subpacket type to make an explicit decision to allow unhashed ADK's -- something which I assume no one would ever have done. I'd also suggest that there should be a careful audit of exactly which subpacket types can legitimately be unhashed. Any unhashed subpacket, other than the allowed types, needs to be rejected (and should probably generate an explicit error, rather than simply being ignored). Another issue that needs to be decided is, if a signature contains both hashed and unhashed subpackets of a given type, whether all the subpackets should be accepted, or whether the hashed subpacket should override the unhashed subpacket (and whether this should cause an error message). Rich Wales richw@webcom.com http://www.webcom.com/richw/ PGP 2.6+ key generated 2000-08-26; all previous encryption keys REVOKED. RSA, 2048 bits, ID 0xFDF8FC65, print 2A67F410 0C740867 3EF13F41 528512FA -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv Comment: Rich Wales's public keys at http://www.webcom.com/richw/pgp/ iQEVAwUBOcLGiUm4X0z9+PxlAQEBXggAyE3ittlbuVb1i/L5jcYr8hfTmh2q5o9X SGTUvB5nlWu7Egulw7YX6GV8N0T2mAo2tqBYdlV2fk2x6mBn9rzPWmRL/3AFSmri 5d/iZ7vExX1hRS5kguBn5+p185qHCvkQ6xoVrmADTj8LbK+m8EYZ2jktGRovd+k0 DTdqT3aLEdNZNtvrJ8AEMsyhGUf1Feu6f+8ISPwPf6+yyNCFGWVbDqE/fgpxcBO6 CW+NGoJmXyGMhNa+97tI1sj2dWnz2p8vm1mjF0wocYgPbd7hKG9WZEt2HyM0oiIC qkLfw6T1LZGvyQLZ3+Ug/NsmCZ4Xt6beuL8Tjwp3RPA/y5mdHskR2Q== =PoJa -----END PGP SIGNATURE-----