* 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
* g10/parse-packet.c (can_handle_critical): Check content length
before calling can_handle_critical_notation.
--
The problem was found by Jan Bee and gniibe proposed the used fix.
Thanks.
This bug can't be exploited: Only if the announced length of the
notation is 21 or 32 a memcmp against fixed strings using that length
would be done. The compared data is followed by the actual signature
and thus it is highly likely that not even read of unallocated memory
will happen. Nevertheless such a bug needs to be fixed.
Signed-off-by: Werner Koch <wk@gnupg.org>
* scd/app-openpgp.c (get_public_key): correctly close 'fp' upon use.
--
Inside the get_public_key function, 'fp' was opened using popen, but
incorrectly closed using fclose.
Debian-Bug-Id: 773474
* g10/keygen.c (generate_subkeypair): Release DEK soon.
--
This fixes the out_of_core error in the test case of adding
RSA-4096 subkey to RSA-4096 primary key with configuration:
s2k-cipher-algo S10
Debian-bug-id: 772780
* g10/parse-packet.c (dump_sig_subpkt): Print regex subpacket
sanitized.
--
We may not use "%s" to print an arbitrary buffer. At least "%.*s"
should have been used. However, it is in general preferable to escape
control characters while printf user data.
Reported-by: Hanno Böck
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from commit 596ae9f543)
* g10/parse-packet.c (parse_attribute_subpkts): Check that the
attribute packet is large enough for the subpacket type.
--
Reported-by: Hanno Böck
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from commit 0988764397)
* g10/mainproc.c (proc_encrypted): Take care of canceled passpharse
entry.
--
GnuPG-bug-id: 1761
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from commit 32e85668b8)
* g10/openfile.c (open_sigfile): Factor some code out to ...
(get_matching_datafile): new function.
* g10/plaintext.c (hash_datafiles): Do not try to find matching file
in batch mode.
* g10/mainproc.c (check_sig_and_print): Print a warning if a possibly
matching data file is not used by a standard signatures.
--
Allowing to use the abbreviated form for detached signatures is a long
standing bug which has only been noticed by the public with the
release of 2.1.0. :-(
What we do is to remove the ability to check detached signature in
--batch using the one file abbreviated mode. This should exhibit
problems in scripts which use this insecure practice. We also print a
warning if a matching data file exists but was not considered because
the detached signature was actually a standard signature:
gpgv: Good signature from "Werner Koch (dist sig)"
gpgv: WARNING: not a detached signature; \
file 'gnupg-2.1.0.tar.bz2' was NOT verified!
We can only print a warning because it is possible that a standard
signature is indeed to be verified but by coincidence a file with a
matching name is stored alongside the standard signature.
Reported-by: Simon Nicolussi (to gnupg-users on Nov 7)
Signed-off-by: Werner Koch <wk@gnupg.org>
(backported from commit 69384568f6)
Updated doc/gpg.texi.
* g10/options.h (IMPORT_KEEP_OWNERTTRUST): New.
* g10/import.c (parse_import_options): Add "keep-ownertrust".
(import_one): Act upon new option.
--
This option is in particular useful to convert from a pubring.gpg to
the new pubring.kbx in GnuPG 2.1 or vice versa:
gpg1 --export | gpg2 --import-options keep-ownertrust --import
(cherry-picked from commit da95d0d378)
* configure.ac: Added --enable-large-secmem option.
* g10/options.h: Add opt.flags.large_rsa.
* g10/gpg.c: Contingent on configure option: adjust secmem size,
add gpg --enable-large-rsa, bound to opt.flags.large_rsa.
* g10/keygen.c: Adjust max RSA size based on opt.flags.large_rsa
* doc/gpg.texi: Document --enable-large-rsa.
--
Some older implementations built and used RSA keys up to 16Kib, but
the larger secret keys now fail when used by more recent GnuPG, due to
secure memory limitations.
Building with ./configure --enable-large-secmem will make gpg
capable of working with those secret keys, as well as permitting the
use of a new gpg option --enable-large-rsa, which let gpg generate RSA
keys up to 8Kib when used with --batch --gen-key.
Debian-bug-id: 739424
Minor edits by wk.
GnuPG-bug-id: 1732
* doc/Makefile.am (sources_from_trunk): Remove.
(update-source): Make it a dummy.
* doc/gpg.texi: Update.
* doc/yat2m.c: Update.
--
Maintaining 3 versions in of the gpg manual in one file is getting
more complicated with 2.1. Thus we stop this now and keep the manual
for 1.4 separate.
* mpi/mpi-inv.c (mpi_invm): Return 0 for bad input.
--
Without this patch the function may enter an endless loop. This is a
backport from libgcrypt.
GnuPG-bug-id: 1713
* include/types.h (GNUPG_GCC_ATTR_UNUSED): Define for gcc >= 3.5.
* mpi/mpih-div.c (mpihelp_divmod_1, mpihelp_mod_1): Mark dummy as
unused.
* mpi/mpi-internal.h (UDIV_QRNND_PREINV): Mark _ql as unused.
--
Due to the use of macros and longlong.h, we use variables which are
only used by some architectures. At least gcc 4.7.2 prints new
warnings about set but not used variables. This patch silences them.
* g10/mainproc.c (proc_compressed): Remove superfluous check for
an algorithm number of 0.
--
(backport from commit 88633bf3d4)
GnuPG-bug-id: 1326, 1684
* g10/keygen.c (gen_elg): Enforce keysize 1024 to 4096.
(gen_rsa): Enforce keysize 1024 to 4096.
(gen_dsa): Enforce keysize 768 to 3072.
--
It was possible to create 16k RSA keys in batch mode. In addition to
the silliness of such keys, they have the major drawback that GnuPG,
with its limited amount of specially secured memory areas, the use of
such keys may lead to an "out of secure memory" condition.
* g10/keyserver.c (ks_retrieval_filter_arg_s): new.
(keyserver_retrieval_filter): Use new struct and check all
descriptions.
(keyserver_spawn): Pass filter arg suing the new struct.
--
This is a fix for commit 52303043.
The old code did only work for a single key. It failed as soon as
several keys are specified ("gpg --refresh-keys" or "gpg --recv-key A
B C").
* g10/main.h: Typedef import_filter for filter callbacks.
* g10/import.c (import): Add filter callbacks to param list.
(import_one): Ditto.
(import_secret_one): Ditto.
(import_keys_internal): Ditto.
(import_keys_stream): Ditto.
* g10/keyserver.c (keyserver_retrieval_filter): New.
(keyserver_spawn): Pass filter to import_keys_stream()
--
These changes introduces import functions that apply a constraining
filter to imported keys. These filters can verify the fingerprints of
the keys returned before importing them into the keyring, ensuring that
the keys fetched from the keyserver are in fact those selected by the
user beforehand.
Signed-off-by: Stefan Tomanek <tomanek@internet-sicherheit.de>
Re-indention and minor changes by wk.
* g10/keylist.c (list_keyblock_colon): Print field 16.
--
We have this info already in gnupg-2 and it is easy to add it to 1.4.
Debian-bug-id: 672658
Patch written and tested by Daniel Leidert. See above.
* g10/encr-data.c (decrypt_data): Do not distinguish between a bad MDC
packet header and a bad MDC.
--
The separate diagnostic was introduced for debugging a problems. For
explaining an MDC error a single error message is easier to understand.
