Package: gnupg
Version: 1.4.14-1
Severity: normal
Tags: patch upstream
Control: -1 forwarded
http://thread.gmane.org/gmane.comp.encryption.gpg.devel/17712/focus=18138
FC 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 has been fixed in the master branch already, but no fix is
available yet upstream for 1.4.x.
The attached patch should work for debian.
Regards,
--dkg
[0] https://tools.ietf.org/html/rfc4880#section-5.2.3.21
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (200, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.11-rc4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages gnupg depends on:
ii gpgv 1.4.14-1
ii libbz2-1.0 1.0.6-5
ii libc6 2.17-92+b1
ii libreadline6 6.2+dfsg-0.1
ii libusb-0.1-4 2:0.1.12-23.2
ii zlib1g 1:1.2.8.dfsg-1
Versions of packages gnupg recommends:
ii gnupg-curl 1.4.14-1
ii libldap-2.4-2 2.4.31-1+nmu2+b1
Versions of packages gnupg suggests:
ii eog 3.8.2-1
pn gnupg-doc <none>
ii libpcsclite1 1.8.8-4
ii xloadimage 4.1-21
-- debconf-show failed
commit 8f8f3984e82a025cf1384132a419f67f39c7e07d
Author: Werner Koch <w...@gnupg.org>
Date: Fri Mar 15 15:46:03 2013 +0100
gpg: Distinguish between missing and cleared key flags.
* include/cipher.h (PUBKEY_USAGE_NONE): New.
* g10/getkey.c (parse_key_usage): Set new flag.
--
We do not want to use the default capabilities (derived from the
algorithm) if any key flags are given in a signature. Thus if key
flags are used in any way, the default key capabilities are never
used.
This allows to create a key with key flags set to all zero so it can't
be used. This better reflects common sense.
Modified g10/getkey.c
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1494,13 +1494,19 @@
if(flags)
key_usage |= PUBKEY_USAGE_UNKNOWN;
+
+ if (!key_usage)
+ key_usage |= PUBKEY_USAGE_NONE;
}
+ else if (p) /* Key flags of length zero. */
+ key_usage |= PUBKEY_USAGE_NONE;
/* We set PUBKEY_USAGE_UNKNOWN to indicate that this key has a
capability that we do not handle. This serves to distinguish
between a zero key usage which we handle as the default
capabilities for that algorithm, and a usage that we do not
- handle. */
+ handle. Likewise we use PUBKEY_USAGE_NONE to indicate that
+ key_flags have been given but they do not specify any usage. */
return key_usage;
}
--- a/include/cipher.h
+++ b/include/cipher.h
@@ -58,6 +58,11 @@
#define PUBKEY_USAGE_CERT 4 /* key is also good to certify other keys*/
#define PUBKEY_USAGE_AUTH 8 /* key is good for authentication */
#define PUBKEY_USAGE_UNKNOWN 128 /* key has an unknown usage bit */
+#define PUBKEY_USAGE_NONE 256 /* No usage given. */
+#if (GCRY_PK_USAGE_SIGN | GCRY_PK_USAGE_ENCR | GCRY_PK_USAGE_CERT \
+ | GCRY_PK_USAGE_AUTH | GCRY_PK_USAGE_UNKN) >= 256
+# error Please choose another value for PUBKEY_USAGE_NONE
+#endif
#define DIGEST_ALGO_MD5 1
#define DIGEST_ALGO_SHA1 2
