* cipher/rsa.c (rsa_sign): Verify after sign.
* g10/gpg.c (opts): Make --no-sig-create-check a NOP.
* g10/options.h (opt): Remove field "no_sig_create_check".
* g10/sign.c (do_sign): Do check only for DSA.
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/getkey.c (get_seckey): Return G10ERR_NO_PUBKEY when it's not
exact match.
--
In the situation of corrupted .gnupg/ where only private subkey is
available but no corresponding public key of the subkey, the code
returned public primary key which caused mysterious error (for a
user). This fix detects an error earlier.
GnuPG-bug-id: 1422
Debian-Bug-Id: #638619
* g10/free-packet.c (cmp_public_keys, cmp_secret_keys): Compare opaque
data at the first entry of the array when it's unknown algo.
* mpi/mpi-cmp.c (mpi_cmp): Backport libgcrypt 1.5.0's semantics.
--
(backported from 2.0 commit 43429c7869)
GnuPG-bug-id: 1962
* g10/parse-packet.c (parse_key): Check PKTLEN before calling mpi_read
et al.
--
Due to the missing length checks PKTLEN may turn negative. Because
PKTLEN is an unsigned int the malloc in read_rest would try to malloc
a too large number and terminate the process with "error reading rest
of packet: Cannot allocate memory".
Reported-by: Hanno Böck.
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from 2.0 commit 0aac920f23)
* util/pka.c: Rewrite.
(get_pka_info): Add arg fprbuflen. Change callers to pass this.
* util/strgutil.c (ascii_strlwr): New.
* configure.ac: Remove option --disable-dns-pka.
(USE_DNS_PKA): Remove ac_define.
* g10/getkey.c (parse_auto_key_locate): Always include PKA.
--
Note that although PKA is now always build, it will only work if
support for looking up via DNS has not been disabled.
The new PKA only works with the IPGP DNS certtype and shall be used
only to retrieve the fingerprint and optional the key for the first
time. Due to the security problems with DNSSEC the former assumption
to validate the key using DNSSEC is not anymore justified. Instead an
additional layer (e.g. Trust-On-First-Use) needs to be implemented to
track change to the key. Having a solid way of getting a key matching
a mail address is however a must have.
More work needs to go into a redefinition of the --verify-options
pka-lookups and pka-trust-increase. The auto-key-locate mechanism
should also be able to continue key fetching with another method once
the fingerprint has been retrieved with PKA.
Signed-off-by: Werner Koch <wk@gnupg.org>
This is a backport from master.
(backported from commit 2fc27c8696)
* include/mpi.h, mpi/mpiutils.c (mpi_set_cond): New.
* mpi/mpi-pow.c (SIZE_PRECOMP): Rename from SIZE_B_2I3.
(mpi_powm): Access all data in the table and use mpi_set_cond.
--
Access to the precomputed table was indexed by a portion of EXPO,
which could be mounted by a side channel attack. This change fixes
this particular data-dependent access pattern.
* g10/seckey-cert.c (do_check): Call BUG for NULL return of
get_opaque.
--
This is the suggested addition from commit 6f03218. We better run
into an fatal error than into a segv.
Signed-off-by: Werner Koch <wk@gnupg.org>
* g10/build-packet.c (do_secret_key): Check for NULL return from
gcry_mpi_get_opaque.
* g10/keyid.c (hash_public_key): Ditto.
--
This is a backport of 76c8122adf from
master to the STABLE-BRANCH-1-4
On the STABLE-BRANCH-1-4, we may also want to patch g10/seckey-cert.c,
but that has not been done in this patch.
This fix extends commmit 0835d2f44e.
gpg2 --export --no-default-keyring --keyring TESTDATA
With TESTDATA being below after unpacking.
-----BEGIN PGP ARMORED FILE-----
mBMEhdkMmS8BcX8F//8F5voEhQAQmBMEnAAAZwAAo4D/f/8EhQAAAIAEnP8EhQAQ
iBMEnP8AAAAABf8jIID///8EhQYQmBMEnIUAEIgTBKT/AAAAAAUAACCA/f//BIUA
EJgTBJx/AP8ABPPzBJx/AP8ABPPz
=2yE0
-----END PGP ARMORED FILE-----
Reported-by: Jodie Cunningham
[dkg: rebased to STABLE-BRANCH-1-4]
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* keyserver/curl-shim.c (curl_easy_setopt) : ensure that va_end is
called.
--
stdarg(3) says:
Each invocation of va_start() must be matched by a
corresponding invocation of va_end() in the same function.
Observed by Joshua Rogers <honey@internot.info>
Debian-Bug-Id: #773475
[dkg: rebased to STABLE-BRANCH-1-4]
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* g10/armor.c (parse_key_failed_line): New.
(check_input): Watch out for gpgkeys_ error lines.
* g10/filter.h (armor_filter_context_t): Add field key_failed_code.
* g10/import.c (import): Add arg r_gpgkeys_err.
(import_keys_internal): Ditto.
(import_keys_stream): Ditto.
* g10/keyserver.c (keyserver_errstr): New.
(keyserver_spawn): Detect "KEY " lines while sending. Get gpgkeys_err
while receiving keys.
(keyserver_work): Add kludge for better error messages.
--
GnuPG-bug-id: 1832
Note that these changes can be backported to 1.4 but they don't make
sense for 2.1 due to the removal of the keyserver helpers. The error
reporting could be improved even more but given that this is an old
GnuPG branch it is not justified to put too much effort into it.
Signed-off-by: Werner Koch <wk@gnupg.org>
[dkg: rebased to STABLE-BRANCH-1-4]
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* include/host2net.h (buf16_to_ulong, buf16_to_uint): New.
(buf16_to_ushort, buf16_to_u16): New.
(buf32_to_size_t, buf32_to_ulong, buf32_to_uint, buf32_to_u32): New.
--
This fixes sign extension on shift problems. Hanno Böck found a case
with an invalid read due to this problem. To fix that almost all uses
of "<< 24" and "<< 8" are changed by this patch to use an inline
function from host2net.h.
(back ported from commit 2183683bd6)
Signed-off-by: Werner Koch <wk@gnupg.org>
[dkg: rebased to STABLE-BRANCH-1-4]
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* g10/keyring.c (keyring_get_keyblock): Whitelist allowed packet
types.
--
The keyring DB code did not reject packets which don't belong into a
keyring. If for example the keyblock contains a literal data packet
it is expected that the processing code stops at the data packet and
reads from the input stream which is referenced from the data packets.
Obviously the keyring processing code does not and cannot do that.
However, when exporting this messes up the IOBUF and leads to an
invalid read of sizeof (int).
We now skip all packets which are not allowed in a keyring.
Reported-by: Hanno Böck <hanno@hboeck.de>
(back ported from commit f0f71a721c)
[dkg: rebased to STABLE-BRANCH-1-4]
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* g10/build-packet.c (write_fake_data): Take care of a NULL stored as
opaque MPI.
--
Reported-by: Hanno Böck <hanno@hboeck.de>
(back ported from commit 0835d2f44e)
[dkg: rebased to STABLE-BRANCH-1-4]
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* g10/parse-packet.c (parse_trust): Always allocate a packet.
--
Reported-by: Hanno Böck <hanno@hboeck.de>
Signed-off-by: Werner Koch <wk@gnupg.org>
(back ported from commit 3997848786)
[dkg: rebased to STABLE-BRANCH-1-4]
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* g10/parse-packet.c (MAX_KEY_PACKET_LENGTH): New.
(MAX_UID_PACKET_LENGTH): New.
(MAX_COMMENT_PACKET_LENGTH): New.
(MAX_ATTR_PACKET_LENGTH): New.
(parse_key): Limit the size of a key packet to 256k.
(parse_user_id): Use macro for the packet size limit.
(parse_attribute): Ditto.
(parse_comment): Ditto.
--
Without that it is possible to force gpg to allocate large amounts of
memory by using a bad encoded MPI. This would be an too easy DoS.
Another way to mitigate would be to change the MPI read function to
allocate memory dynamically while reading the MPI. However, that
complicates and possibly slows down the code. A too large key packet
is in any case a sign for broken data and thus gpg should not use it.
Reported-by: Hanno Böck
GnuPG-bug-id: 1823
Signed-off-by: Werner Koch <wk@gnupg.org>
(back ported from commit 382ba4b137)
[dkg: rebased to STABLE-BRANCH-1-4]
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* g10/keygen.c (ask_algo): Add list of strings.
--
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from commit b1d5ed6ac8)
[dkg: rebased to STABLE-BRANCH-1-4]
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* g10/keyedit.c (subkey_expire_warning): New.
keyedit_menu): Call it when needed.
--
GnuPG-bug-id: 1715
The heuristic to detect a problem is not very advanced but it should
catch the most common cases.
(backported from commit ae3d1bbb65)
[dkg: rebased to STABLE-BRANCH-1-4]
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* cipher/elgamal.c (USE_BLINDING): New.
(decrypt): Rewrite to use ciphertext blinding.
--
CVE-id: CVE-2014-3591
As a countermeasure to a new side-channel attacks on sliding windows
exponentiation we blind the ciphertext for Elgamal decryption. This
is similar to what we are doing with RSA.
Unfortunately, the performance impact of Elgamal blinding is quite
noticeable: For a 3072 bit Elgamal key the decryption used to take
13ms; with the blinding it takes 24ms. This has been measured using
time(1), calling gpg with a 100 byte message, and having gpg modified
to run the pubkey_decrypt function 100 times and finally scale the
result (using an i5-2410M CPU @ 2.30GHz TP 220).
* cipher/rndlinux.c (rndlinux_gather_random): Check fd before using
FD_SET.
--
If on systems where the maximum number of fds may be dynamically
configured to a value of FD_MAXSIZE or higher and the RNG is first
used after more than FD_SETSIZE-1 descriptors are in use, we disable
the progress messages from the RNG. A better solution would be too
use poll but that requires more tests.
The same problem exists in rndunix.c - however this rng is only used
on old Unices and I assume that they don't feature dynamically
configured maximum fd sizes.
(from Libgcrypt commit 9487099071af4478d2882e633a0ade805801d6fa)
This may fix
GnuPG-bug-id: 1818
* doc/gpl.texi: Fix enumerate and re-indent examples.
--
Cherry-pick a part of ff6115227a.
Reported-by: Ian Abbott
Signed-off-by: Werner Koch <wk@gnupg.org>
* util/iobuf.c: (iobuf_open): initialize len
--
Cherry-pick 367b073ab5.
In iobuf_open, IOBUFCTRL_DESC and IOBUFCTRL_INIT commands are invoked
(via file_filter()) on fcx, passing in a pointer to an uninitialized
len.
With these two commands, file_filter doesn't actually do anything with
the value of len, so there's no actual risk of use of uninitialized
memory in the code as it stands.
However, some static analysis tools might flag this situation with a
warning, and initializing the value doesn't hurt anything, so i think
this trivial cleanup is warranted.
Debian-Bug-Id: 773469
