GnuPG does not detect injection of unsigned data

Type securityvulns
Reporter Securityvulns
Modified 2006-03-10T00:00:00


       GnuPG does not detect injection of unsigned data
             (released 2006-03-09, CVE-2006-0049)


In the aftermath of the false positive signature verfication bug (announced 2006-02-15) more thorough testing of the fix has been done and another vulnerability has been detected.

This new problem affects the use of gpg for verification of signatures which are not detached signatures. The problem also affects verification of signatures embedded in encrypted messages; i.e. standard use of gpg for mails.

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

Please do not respond 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]).


Signature verification of non-detached signatures may give a positive result but when extracting the signed data, this data may be prepended or appended with extra data not covered by the signature. Thus it is possible for an attacker to take any signed message and inject extra arbitrary data.

Detached signatures (a separate signature file) are not affected.

All versions of gnupg prior to are affected.

Scripts and applications using gpg to verify the integrity of data are affected. This includes applications using the GPGME library[2].

The GnuPG version 1.9.x is not affected unless the currently deprecated gpg part has been enabled.


Update GnuPG as soon as possible to version There are no fixes for older versions available.

If you can't get an update from your vendor, please follow the instructions found at or read on:

GnuPG may be downloaded from one of the GnuPG mirror sites or direct from . The list of mirrors can be found at . Note, that GnuPG is not available at

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

gnupg- (2.8M) gnupg-

  GnuPG source compressed using BZIP2 and OpenPGP signature.

gnupg- (4.0M) gnupg-

  GnuPG source compressed using GZIP and OpenPGP signature.

gnupg- (101k)

  A patch file to upgrade a 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.4M) gnupg-w32cli-

  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[3], including a fixed version of GnuPG has also been
  released today.

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. Due to the fact that detached signatures are used, the problem described here does not affect this verification. For example to check the signature of the file gnupg- you would use this command:

    gpg --verify gnupg-

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'" or "finger dd9jn 'at'" 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-, you would run the sha1sum command like this:

    sha1sum gnupg-

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

f5559ddb004e0638f6bd9efe2bac00134c5065ba gnupg- 959540c1c6158e09d668ceee055bf366dc26d0bd gnupg- 880b3e937f232b1ca366bda37c4a959aacbd84f3 gnupg- 95dd7fd4c49423b86704acfc396ce5a53c8b19e7 gnupg-w32cli-


OpenPGP messages are made up of packets. The signed data is a packet, the actual signature is a packet and there are several control packets as well. For example:

O + D + S

This describes a standard signed message made made up of a control packet (O for one-pass signature packet), the actual signed data (D) and the actual signature packet (S). gpg checks that the signature S is valid over the data D. This is actually easy if not OpenPGP and GnuPG would have a long tradition of changing the fromats. PGP 2 versions used a different way of composing these packets:

S + D

and early versions of gpg, released before RFC2440, even created

D + S

i.e. without the one-pass packet. Still this would all be easy to process properly but in an ill-advised attempt to make things easier, gpg allowed the processing of multiple signatures per file, like

O1 + D1 + S1 + O2 + D2 + S2

where two standard signatures are concatenated. Now when combining this with the other variants of signatures, things get really messy and it is not always possible to assocciate the signature (S) with the signed data (D). gpg checked that this all works but unfortunately these checks are not sufficient enough. The attack is to change a standard message to inject faked data (F). A simple case is this:

F + O + D + S

gpg now happily skips F for verification and does a proper signature verification of D and if this succeeds, prints a positive result. However when asked to output the actual signed data it will output the concatenation of F + D and thus create the impression that both are covered by the signature. Depending on how gpg is invoked (in a pipeline or using --output) it may even output just F and not at all D. There are several variants of the attack in where to put the faked data.

The only correct solution to this problem is to get rid of the feature to check concatenated signatures - this allows for strict checking of valid packet composition. This is what has been done in and in the forthcoming 1.4.3rc2. These versions accept signatures only if they are composed of

O + D + S S + D

Cleartext signatures are of course also supported, they are similiar to the O+D+S case.

The actual checking for valid signature packet composition is done at g10/mainproc.c, at the top of check_sig_and_print().


Tavis Ormandy again poked on gpg and found this vulnerability.

The new version has been released yesterday and should by now be available on all mirrors.

[1] [2] [3]

-- Werner Koch <> The GnuPG Experts Free Software Foundation Europe Join the Fellowship and protect your Freedom!