GnuPG can be made to spin on a relatively small input by (for example) crafting a public key with thousands of signatures attached, compressed down to just a few KB; see $URL and the surrounding email threads for more details and test-cases.
The reporter has some proposed patches at https://dev.gnupg.org/D556 (and in oss-security / gnupg-devel threads); mostly these flag/reject compressed packets and indeterminate-length packets in contexts where they make no sense and arguably are not within the spec (certificates, keys, detached signatures).
GnuPG can be made to spin on a relatively small input by (for example) crafting a public key with thousands of signatures attached, compressed down to just a few KB; see $URL and the surrounding email threads for more details and test-cases.
The reporter has some proposed patches at https://dev.gnupg.org/D556 (and in oss-security / gnupg-devel threads); mostly these flag/reject compressed packets and indeterminate-length packets in contexts where they make no sense and arguably are not within the spec (certificates, keys, detached signatures).
GnuPG through 2.3.6, in unusual situations where an attacker possesses any secret-key information from a victim's keyring and other constraints (e.g., use of GPGME) are met, allows signature forgery via injection into the status line.
GnuPG 2.2.21 and 2.2.22 (and Gpg4win 3.1.12) has an array overflow, leading to a crash or possibly unspecified other impact, when a victim imports an attacker's OpenPGP key, and this key has AEAD preferences. The overflow is caused by a g10/key-check.c error. NOTE: GnuPG 2.3.x is unaffected. GnuPG 2.2.23 is a fixed version.
The mpipowm function in Libgcrypt before 1.6.3 and GnuPG before 1.4.19 allows attackers to obtain sensitive information by leveraging timing differences when accessing a pre-computed table during modular exponentiation, related to a "Last-Level Cache Side-Channel Attack."
Libgcrypt before 1.6.3 and GnuPG before 1.4.19 does not implement ciphertext blinding for Elgamal decryption, which allows physically proximate attackers to obtain the server's private key by determining factors using crafted ciphertext and the fluctuations in the electromagnetic field during multiplication.
dirmngr before 2.1.0 improperly handles certain system calls, which allows remote attackers to cause a denial of service (DOS) via a specially-crafted certificate.
kbx/keybox-search.c in GnuPG before 1.4.19, 2.0.x before 2.0.27, and 2.1.x before 2.1.2 does not properly handle bitwise left-shifts, which allows remote attackers to cause a denial of service (invalid read operation) via a crafted keyring file, related to sign extensions and "memcpy with overlapping ranges."
The keyring DB in GnuPG before 2.1.2 does not properly handle invalid packets, which allows remote attackers to cause a denial of service (invalid read and use-after-free) via a crafted keyring file.
Interaction between the sks-keyserver code through 1.2.0 of the SKS keyserver network, and GnuPG through 2.2.16, makes it risky to have a GnuPG keyserver configuration line referring to a host on the SKS keyserver network. Retrieving data from this network may cause a persistent denial of service, because of a Certificate Spamming Attack.
The mixing functions in the random number generator in Libgcrypt before 1.5.6, 1.6.x before 1.6.6, and 1.7.x before 1.7.3 and GnuPG before 1.4.21 make it easier for attackers to obtain the values of 160 bits by leveraging knowledge of the previous 4640 bits.
Integer underflow in the ksbaoidtostr function in Libksba before 1.3.2, as used in GnuPG, allows remote attackers to cause a denial of service (crash) via a crafted OID in a (1) S/MIME message or (2) ECC based OpenPGP data, which triggers a buffer overflow.
The douncompress function in g10/compress.c in GnuPG 1.x before 1.4.17 and 2.x before 2.0.24 allows context-dependent attackers to cause a denial of service (infinite loop) via malformed compressed packets, as demonstrated by an a3 01 5b ff byte sequence.
GnuPG 1.x before 1.4.16 generates RSA keys using sequences of introductions with certain patterns that introduce a side channel, which allows physically proximate attackers to extract RSA keys via a chosen-ciphertext attack and acoustic cryptanalysis during decryption. NOTE: applications are not typically expected to protect themselves from acoustic side-channel attacks, since this is arguably the responsibility of the physical device. Accordingly, issues of this type would not normally receive a CVE identifier. However, for this issue, the developer has specified a security policy in which GnuPG should offer side-channel resistance, and developer-specified security-policy violations are within the scope of CVE.
The compressed packet parser in GnuPG 1.4.x before 1.4.15 and 2.0.x before 2.0.22 allows remote attackers to cause a denial of service (infinite recursion) via a crafted OpenPGP message.
GnuPG 1.4.x, 2.0.x, and 2.1.x treats a key flags subpacket with all bits cleared (no usage permitted) as if it has all bits set (all usage permitted), which might allow remote attackers to bypass intended cryptographic protection mechanisms by leveraging the subkey.
GnuPG before 1.4.14, and Libgcrypt before 1.5.3 as used in GnuPG 2.0.x and possibly other products, allows local users to obtain private RSA keys via a cache side-channel attack involving the L3 cache, aka Flush+Reload.
KB Sriram (kbsriram) reports:
Versions of GnuPG <= 1.4.12 are vulnerable to memory access violations and public keyring database corruption when importing public keys that have been manipulated.
An OpenPGP key can be fuzzed in such a way that gpg segfaults (or has other memory access violations) when importing the key.
The key may also be fuzzed such that gpg reports no errors when examining the key (eg: "gpg thebadkey.pkr") but importing it causes gpg to corrupt its public keyring database.
The database corruption issue was first reported on Dec 6th, through the gpg bug tracking system:
https://bugs.g10code.com/gnupg/issue1455
The subsequent memory access violation was discovered and reported in a private email with the maintainer on Dec 20th.
A zip file with keys that causes segfaults and other errors is available at http://dl.dropbox.com/u/18852638/gnupg-issues/1455.zip and includes a log file that demonstrates the issues [on MacOS X and gpg 1.4.11]
A new version of gpg -- 1.4.13 -- that addressed both these issues, was independently released by the maintainer on Dec 20th.
The simplest solution is to upgrade all gpg installs to 1.4.13.
[Workarounds: A corrupted database may be recovered by manually copying back the pubring.gpg~ backup file. Certain errors may also be prevented by never directly importing a key, but first just "looking" at the key (eg: "gpg badkey.pkr"). However, this is not guaranteed to work in all cases; though upgrading to 1.4.13 does work for the issues reported.]
Discovery:
The problem was discovered during a byte-fuzzing test of OpenPGP certificates for an unrelated application. Each byte in turn was replaced by a random byte, and the modified certificate fed to the application to check that it handled errors correctly. Gpg was used as a control, but it itself turned out to have errors related to packet parsing. The errors are generally triggered when fuzzing the length field of OpenPGP packets, which cascades into subsequent errors in certain situations.
External references: https://bugs.g10code.com/gnupg/issue1455 http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commitdiff;h=f0b33b6fb8e0586e9584a7a409dcc31263776a67
Use-after-free vulnerability in kbx/keybox-blob.c in GPGSM in GnuPG 2.x through 2.0.16 allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via a certificate with a large number of Subject Alternate Names, which is not properly handled in a realloc operation when importing the certificate or verifying its signature.
GnuPG (gpg) 1.4.8 and 2.0.8 allows remote attackers to cause a denial of service (crash) and possibly execute arbitrary code via crafted duplicate keys that are imported from key servers, which triggers "memory corruption around deduplication of user IDs."