Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 484836 (CVE-2013-4351) - <app-crypt/gnupg-{1.4.15,2.0.22}: GnuPG treats no-usage-permitted keys as all-usages-permitted (CVE-2013-4351)
Summary: <app-crypt/gnupg-{1.4.15,2.0.22}: GnuPG treats no-usage-permitted keys as all...
Alias: CVE-2013-4351
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
Whiteboard: A4 [glsa]
Depends on: CVE-2013-4402
  Show dependency tree
Reported: 2013-09-14 06:47 UTC by Agostino Sarubbo
Modified: 2014-02-21 16:08 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Agostino Sarubbo gentoo-dev 2013-09-14 06:47:33 UTC
From ${URL} :

RFC 4880 permits OpenPGP keyholders to mark their primary keys and
subkeys with a "key flags" packet that indicates the capabilities of the
key [0].  These are represented as a set of binary flags, including
things like "This key may be used to encrypt communications."

If a key or subkey has this "key flags" subpacket attached with all bits
cleared (off), GnuPG currently treats the key as having all bits set
(on).  While keys with this sort of marker are very rare in the wild,
GnuPG's misinterpretation of this subpacket could lead to a breach of
confidentiality or a mistaken identity verification.

Potential Confidentiality Breach

For example, if Alice has a subkey X whose "key flags" subpacket has all
bits cleared (because she is using it for something not documented in
the spec, perhaps something experimental or risky), and Bob sends Alice
an e-mail encrypted using GnuPG, Bob may accidentally encrypt the
message to key X, depsite Alice having clearly stated that the key is
not to be used for encrypted communications.  If Alice's intended use of
X turns out to compromise the key itself somehow, then the attacker can
read Bob's otherwise confidential communication to Alice.

Potential Mistaken Identity Verification

Consider the scenario above, but where Bob is in general willing to rely
on OpenPGP certifications made by Alice.  The legitimate form of these
certifications are usually made by Alice's primary key, which is marked
as "certification-capable".  Because Bob's GnuPG misinterprets the usage
flags on subkey X, Bob may be able to be tricked into believing that
Alice has certified someone else's OpenPGP identity if an attacker
manages to coax Alice into using subkey X in a way that is replayable as
an OpenPGP certification.

These risks are unlikely today (there are very few certifications in the
wild with an all-zero key flags subpacket), and they are not
particularly dangerous (for a compromise to happen, there needs to also
be a cross-context abuse of the mis-classified key, which i do not have
a concrete example of).  But the keyholder's stated intent of separating
out keys by context of use is being ignored, so there is a window of
vulnerability that should not be open.

There is also a (maybe non-security) functionality issue here, in that
GnuPG may mis-use the user's own keys if they are marked as described
above (e.g. signing messages or certifying identities with a subkey that
is explicitly marked as not being for that purpose).

This problem was first reported to the GnuPG team back in March [1].
Patches are available, but appear to only be applied on the development
branch (2.1.x).  So stable branches 1.4.x and 2.0.x remain vulnerable at
the moment.

@maintainer(s): after the bump, in case we need to stabilize the package, please say explicitly if it is ready for the stabilization or not.
Comment 1 Yury German Gentoo Infrastructure gentoo-dev 2013-10-03 03:49:35 UTC
Looks like there are patches available:

Adding a number of URL's for reference including patch URLs for OpenSuse and Debian.

General Information URL's:

Patch Information from Debian:
Patch Information from OpenSuse:

Moving Whiteboard to ebuild
Comment 3 Alon Bar-Lev (RETIRED) gentoo-dev 2013-10-04 22:24:37 UTC
Fixed in gnupg-2.0.21-r2
Comment 4 Sean Amoss (RETIRED) gentoo-dev Security 2013-10-15 10:35:07 UTC
This has been included in an existing GLSA draft.
Comment 5 GLSAMaker/CVETool Bot gentoo-dev 2013-10-16 02:18:09 UTC
CVE-2013-4351 (
  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.
Comment 6 Alon Bar-Lev (RETIRED) gentoo-dev 2013-10-22 17:11:14 UTC
crypto done
Comment 7 GLSAMaker/CVETool Bot gentoo-dev 2014-02-21 16:08:31 UTC
This issue was resolved and addressed in
 GLSA 201402-24 at
by GLSA coordinator Chris Reffett (creffett).