Home page logo
/

oss-sec logo oss-sec mailing list archives

Re: GnuPG treats no-usage-permitted keys as all-usages-permitted
From: Kurt Seifried <kseifried () redhat com>
Date: Fri, 13 Sep 2013 13:15:22 -0600

-----BEGIN PGP SIGNED MESSAGE-----
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] https://tools.ietf.org/html/rfc4880#section-5.2.3.21 [1]
http://thread.gmane.org/gmane.comp.encryption.gpg.devel/17712/focus=18138


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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJSM2RKAAoJEBYNRVNeJnmTcakQAMXS9Myd4ZpJeqGCX3dZlTHj
rU4u//iuOC3cfRYwYV8EycQdAxkdXKGt5Fc2ZImjhwNiY70b9Luq+5MGPlDHRM1n
vojp65uKJRHmiWrAsIMZJQiKDKdYtNys/rWh5YEbptUIIjILSyPCpO7vw8CAlAWW
vwi4OYQoWKrPKt7vyRsTGd2kaKK4yhs3Lt3ULC9olbIE8M4qa7CXwc6+uO44jMLu
MLToG7gHT3Y0hun6O58736vemkS/3Iqh1G0QRLWUZGj2qPC6u30OxpuwFIyDaZSu
ng5+5zOfUyLnZNE6tdPcx1io2Dm5VaRE0gtM4HknNEHf8t2u8LOExWhTU5g0yR5e
nyq0dKrTTG84nGSw/HRINXV0v2hbSpyA15Pz4gQoZ3KMkflCSw4XOlelT6sA2PCe
sJkUWXGy/lgNC8PUUV7IH1uWkP7RSqh8oam3bD4h6ZBpZlodDXzwKBvSG5V9cdL7
PKGZKfAzETueBAxKPXmYWLf9KRXZsulfud6yRctIa1n27C/wSSTw1L9VBY1XY4Ko
ILT3Lg0tTk/Y/Q1YC2QgtAQu6u2jPUdXiDY1d2D5tv5EvxDTZUCipSpcw8LnGnjc
pnvJ3XrbyDHxLe6nzSJwm/5NO5cKmq7uklr7SYIEhyPvuCFlC/NvD1rtfLhcsbxp
iGpgXUg54W9hL1m4OA3u
=Dg6j
-----END PGP SIGNATURE-----


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]