(fwd) PGP "unhashed subpacket" problem possibly more serious

[Daniel Hartmeier <daniel_(_at_)_reichardt_(_dot_)_ch>]

ports/security/pgp5 is affected.

----------------------------- begin quote -----------------------------

Date: Fri, 15 Sep 2000 10:59:59 -0700 (PDT)
From: Rich Wales <richw_(_at_)_webcom_(_dot_)_com>
To: cert_(_at_)_cert_(_dot_)_org
Cc: Phil Zimmermann <prz_(_at_)_pgp_(_dot_)_com>, Mark McArdle <mmcardle_(_at_)_nai_(_dot_)_com>,
    Ralf Senderek <ralf_(_at_)_senderek_(_dot_)_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_(_at_)_webcom_(_dot_)_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

------------------------------ end quote ------------------------------