security-and-privacy/gnupg
security-and-privacy/gnupg
1
0
Fork 0
mirror of git://git.gnupg.org/gnupg.git synced 2024-11-10 21:38:50 +01:00
Code Activity
99fb609e0a
gnupg/doc/detached-sig-verification-bug.txt
Werner Koch a917165bef keep on walking towards rc3
2006-03-09 19:24:59 +00:00

7.8 KiB
Raw Blame History 

       False positive signature verification in GnuPG
       ==============================================
                   (released 2006-02-15)

Summary

The Gentoo project identified a security related bug in GnuPG. When using any current version of GnuPG for unattended signature verification (e.g. by scripts and mail programs), false positive signature verification of detached signatures may occur.

This problem affects the tool gpgv, as well as using "gpg --verify" to imitate gpgv, if only the exit code of the process is used to decide whether a detached signature is valid. This is a plausible mode of operation for gpgv.

If, as suggested, the --status-fd generated output is used to decide whether a signature is valid, no problem exists. In particular applications making use of the GPGME library[2] are not affected.

To solve this problem an update of the current stable version has been released (see below).

Please do not send private mail in response to this message. The mailing list gnupg-devel is the best place to discuss this problem (please subscribe first so you don't need moderator approval [1]).

Impact:

Signature verification of detached signatures does not work, thus modified versions of signature protected files may not be detected.

All versions of gnupg prior to 1.4.2.1 are affected if they are used in certain unattended operation modes.

There is no problem using GnuPG in an interactive way because GnuPG won't print any signature status at all; i.e. no "Good signature".

Scripts and applications using gpg or gpgv with the --status-fd option and properly parsing this output are not affected.

Applications using the GPGME library[2] are not affected.

The GnuPG versions 1.9 are not affected unless the currently deprecated gpg part has been enabled.

Solution:

Update GnuPG as soon as possible to version 1.4.2.1. There are no fixes for older versions available, although the fix described below may be adjusted for them.

To update please follow the instructions found at http://www.gnupg.org/download/ or read on:

GnuPG 1.4.2.1 may be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt/ . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org.

On the mirrors you should find the following files in the gnupg directory:

gnupg-1.4.2.1.tar.bz2 (2.8M) gnupg-1.4.2.1.tar.bz2.sig

  GnuPG source compressed using BZIP2 and OpenPGP signature.

gnupg-1.4.2.1.tar.gz (4.0M) gnupg-1.4.2.1.tar.gz.sig

  GnuPG source compressed using GZIP and OpenPGP signature.

gnupg-1.4.2-1.4.2.1.diff.bz2 (39k)

  A patch file to upgrade a 1.4.2 GnuPG source.

Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date.

In the binary directory, you should find these files:

gnupg-w32cli-1.4.2.1.exe (1.4M) gnupg-w32cli-1.4.2.1.exe.sig

  GnuPG compiled for Microsoft Windows and OpenPGP signature.
  Note that this is a command line version and now comes with a
  graphical installer tool.  The source files are the same as
  given above.  Note, that a new version of the Gpg4Win
  package[4], including an updated version of GnuPG will be
  available later the day.

In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways:

  • If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.4.2.1.tar.bz2 you would use this command:

    gpg --verify gnupg-1.4.2.1.tar.bz2.sig

    This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using "finger wk 'at' g10code.com" or "finger dd9jn 'at' gnu.org" or using the keyservers. From time to time I prolong the expiration date; thus you might need a fresh copy of that key.

    Never use a GnuPG version you just downloaded to check the integrity of the source - use an existing GnuPG installation! Watch out for a "Good signature" messages.

  • If you are not able to use an old version of GnuPG, you have to verify the SHA-1 checksum. Assuming you downloaded the file gnupg-1.4.2.1.tar.bz2, you would run the sha1sum command like this:

    sha1sum gnupg-1.4.2.1.tar.bz2

    and check that the output matches the first line from the following list:

1c0306ade25154743d6f6f9ac05bee74c55c6eda gnupg-1.4.2.1.tar.bz2 cefc74560f21bde74eed298d86460612cd7e12ee gnupg-1.4.2.1.tar.gz 98d597b1a9871b4aadc820d8641b36ce09125612 gnupg-1.4.2-1.4.2.1.diff.bz2 a4db35a72d72df8e76751adc6f013b4c96112fd4 gnupg-w32cli-1.4.2.1.exe

Background:

If a file with arbitrary data, for example 64 times the character 0xCA, is used as the detached signature, any data file will lead to gpg exiting with 0 (success). There won't be any messages indicating that the signature is valid or false:

$ fortune >x.txt $ perl -e 'print "\xca"x"64"' >x.txt.sig $ gpgv x.txt.sig x.txt echo? 0

Cleary this should not return success.

The same problem appears when using "gpg --verify" in place of gpgv. However in this case any application should to do further checks to make sure that the key verifying the signature is actually the desired one, thus using "gpg --verify" without processing the --status-fd generated output is in general the wrong approach.

The fixed version makes sure that gpgv and "gpg --verify" won't return success if no signature has been seen. A minimal but sufficient fix against 1.4.2 and possible older versions is:

====8<============ --- g10/mainproc.c (revision 4001) +++ g10/mainproc.c (working copy) @@ -77,6 +77,7 @@ int op; int stop_now; } pipemode;

  • int any_sig_seen; /* Set to true if a signature packet has been seen. */ };

@@ -217,6 +218,7 @@ { KBNODE node;

  • c->any_sig_seen = 1; if( pkt->pkttype == PKT_SIGNATURE && !c->list ) { /* This is the first signature for the following datafile.
    • GPG does not write such packets; instead it always uses @@ -1137,6 +1139,18 @@ c->signed_data = signedfiles; c->sigfilename = sigfilename; rc = do_proc_packets( c, a );
  • /* If we have not encountered any signature we print an error
  •   messages, send a NODATA status back and return an error code.

  •   Using log_error is required because verify_files does not check

  •   error codes for each file but we want to terminate the process

  •   with an error. */
  • if (!rc && !c->any_sig_seen)
  •  {
  • write_status_text (STATUS_NODATA, "4");
  •    log_error (_("no signature found\n"));

  •    rc = -1;

  •  }
    m_free( c ); return rc; } ====>8============

Note that the released version also includes a test case for this bug and prints an additional diagnostic. With the patch above the output using the same test data as above should be:

$ gpgv x.txt.sig x.txt gpgv: no signature found gpgv: verify signatures failed: eof echo? 2

Thanks

taviso from the Gentoo project found this vulnerability and informed me on Monday evening. Unfortunately I had already switched off my monitor at that time. The update has been released yesterday evening (CET).

[1] http://lists.gnupg.org/mailman/listinfo/gnupg-devel [2] http://www.gnupg.org/related_software/gpgme [3] http://www.gpg4win.org