Gnupg announce - Oct 2000 - GPG 1.0.3 doesn't detect modifications to files with multiple signatures

Hi!

Jim is right.  There is a bug in all GnuPG versions up to 1.0.3:

If you have more than one cleartext signature in a file (or pipe
that to gpg), gpg does not compare each signature but flags each
document as good or bad depending on the first document in the file.

This is a very serious bug in gpg's verification function.

I have made a snapshot version which corrects this bug available at:
  
  ftp://ftp.guug.de/gcrypt/devel/gnupg-1.0.3b.tar.gz      (1681k) 
  ftp://ftp.guug.de/gcrypt/devel/gnupg-1.0.3b.tar.gz.sig

This version also comes with AES support but there are still the
same problems with building on Solaris and HP/UX as in 1.0.3.  We
are currently working on large file support and the compilations
problems.  A regular release should be available in a few days.

Some background: To check cleartext signatures, GnuPG uses the same
dearmoring code as everywhere and this code works just like a filter
which decoded the base-64 armor and feeds it into the normal
processing.  When it comes to cleartext signatures, the armor code
fakes 2 packet: The first one is a so called one-pass packet, which
tells the further processing stuff how the plaintext should be
hashed and a literal data packet which contains the signed material.
This way it is not easy to detect the cleartext signed part which is
needed to reset the internal state of gpg.  The new solution (which
is something I should have done from the beginning) is to create a
new control packet, which is taken out of the special private packet
number space and use this to transfer the meta information about the
cleartext signature to the verification engine.  To avoid problems
with control packets send to gpg over the normal input, the faked
packets are now tagged with a random string during creation and the
packet parser code accepts this control packet only when it contains
this tag.

This problem has been in GnuPG since the beginning but Jim's seems
to be the first one who noiced that.  We need better auditing folks!
This bug is just one more prove that "given enough eyeballs all bugs
are shallow" can not be held true when it comes to the security
bugs; well, the bugs are probably found faster - but most times only
be coincedence.

BTW, I'd would have appreciated it if Jim had reported that bug
through the usual GnuPG bug address or to the developers mailing list.
To give us a day or so to analyze the thing and prepare a patch.


  Werner
  
-- 
Werner Koch				GnuPG key:  621CC013
OpenIT GmbH                             http://www.OpenIT.de