Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 13 Sep 2013 13:15:22 -0600
From: Kurt Seifried <>
CC: Daniel Kahn Gillmor <>
Subject: Re: GnuPG treats no-usage-permitted keys as all-usages-permitted

Hash: SHA1

On 09/13/2013 12:32 AM, Daniel Kahn Gillmor wrote:
> 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.
> Could a CVE be issued for this?
> Regards,
> --dkg
> [0] [1]
Please use CVE-2013-4351 for this issue.

- -- 
Kurt Seifried Red Hat Security Response Team (SRT)
PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Version: GnuPG v1.4.14 (GNU/Linux)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.