IBM argues that in certain scenarios capability query is really
expensive. At the same time it's asserted that query results can
be safely cached, because disabling CPACF is incompatible with
reboot-free operation.
Harden ASN.1 BIO handling of large amounts of data.
If the ASN.1 BIO is presented with a large length field read it in
chunks of increasing size checking for EOF on each read. This prevents
small files allocating excessive amounts of data.
CVE-2016-2109
Thanks to Brian Carpenter for reporting this issue.
Andy Polyakov [Thu, 31 Mar 2016 16:47:17 +0000 (18:47 +0200)]
PPC assembly pack: remove branch hints.
As it turns out branch hints grew as kind of a misconception. In
addition their interpretation by GNU assembler is affected by
assembler flags and can end up with opposite meaning on different
processors. As we have to loose quite a lot on misinterprerations,
especially on newer processors, we just omit them altogether.
David Benjamin [Mon, 14 Mar 2016 19:03:07 +0000 (15:03 -0400)]
Fix memory leak on invalid CertificateRequest.
Free up parsed X509_NAME structure if the CertificateRequest message
contains excess data.
The security impact is considered insignificant. This is a client side
only leak and a large number of connections to malicious servers would
be needed to have a significant impact.
This was found by libFuzzer.
Reviewed-by: Emilia Käsper <emilia@openssl.org> Reviewed-by: Stephen Henson <steve@openssl.org>
Todd Short [Sat, 5 Mar 2016 13:47:55 +0000 (08:47 -0500)]
Fix ALPN
* Perform ALPN after the SNI callback; the SSL_CTX may change due to
that processing
* Add flags to indicate that we actually sent ALPN, to properly error
out if unexpectedly received.
* document ALPN functions
* unit tests
Matt Caswell [Mon, 14 Mar 2016 17:06:19 +0000 (17:06 +0000)]
Fix a potential double free in EVP_DigestInit_ex
There is a potential double free in EVP_DigestInit_ex. This is believed
to be reached only as a result of programmer error - but we should fix it
anyway.
Richard Levitte [Wed, 9 Mar 2016 10:36:32 +0000 (11:36 +0100)]
Touch the correct variables for the system; shlib_wrap.sh on Solaris
If there is cause to think LD_LIBRARY_PATH_32 and LD_PRELOAD_32 are
appropriate variables to touch, do so. Otherwise, touch the usual
LD_LIBRARY_PATH and LD_PRELOAD. This covers for older installations
that don't have a mix of 32-bit and 64-bit libs.
Andy Polyakov [Fri, 4 Mar 2016 10:39:11 +0000 (11:39 +0100)]
bn/asm/x86[_64]-mont*.pl: complement alloca with page-walking.
Some OSes, *cough*-dows, insist on stack being "wired" to
physical memory in strictly sequential manner, i.e. if stack
allocation spans two pages, then reference to farmost one can
be punishable by SEGV. But page walking can do good even on
other OSes, because it guarantees that villain thread hits
the guard page before it can make damage to innocent one...
PVK files with abnormally large length or salt fields can cause an
integer overflow which can result in an OOB read and heap corruption.
However this is an rarely used format and private key files do not
normally come from untrusted sources the security implications not
significant.
Fix by limiting PVK length field to 100K and salt to 10K: these should be
more than enough to cover any files encountered in practice.
At the same time remove miniscule bias in final subtraction.
Performance penalty varies from platform to platform, and even with
key length. For rsa2048 sign it was observed to be 4% for Sandy
Bridge and 7% on Broadwell.
CVE-2016-0702
Reviewed-by: Richard Levitte <levitte@openssl.org> Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from master)
Matt Caswell [Fri, 19 Feb 2016 11:38:25 +0000 (11:38 +0000)]
Add a test for SSLv2 configuration
SSLv2 should be off by default. You can only turn it on if you have called
SSL_CTX_clear_options(SSL_OP_NO_SSLv2) or
SSL_clear_options(SSL_OP_NO_SSLv2). You should not be able to inadvertantly
turn it on again via SSL_CONF without having done that first.
Viktor Dukhovni [Thu, 18 Feb 2016 02:07:48 +0000 (21:07 -0500)]
Disable SSLv2 default build, default negotiation and weak ciphers.
SSLv2 is by default disabled at build-time. Builds that are not
configured with "enable-ssl2" will not support SSLv2. Even if
"enable-ssl2" is used, users who want to negotiate SSLv2 via the
version-flexible SSLv23_method() will need to explicitly call either
of:
SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
or
SSL_clear_options(ssl, SSL_OP_NO_SSLv2);
as appropriate. Even if either of those is used, or the application
explicitly uses the version-specific SSLv2_method() or its client
or server variants, SSLv2 ciphers vulnerable to exhaustive search
key recovery have been removed. Specifically, the SSLv2 40-bit
EXPORT ciphers, and SSLv2 56-bit DES are no longer available.
Matt Caswell [Mon, 22 Feb 2016 10:27:18 +0000 (10:27 +0000)]
Fix BN_hex2bn/BN_dec2bn NULL ptr/heap corruption
In the BN_hex2bn function the number of hex digits is calculated using
an int value |i|. Later |bn_expand| is called with a value of |i * 4|.
For large values of |i| this can result in |bn_expand| not allocating any
memory because |i * 4| is negative. This leaves ret->d as NULL leading
to a subsequent NULL ptr deref. For very large values of |i|, the
calculation |i * 4| could be a positive value smaller than |i|. In this
case memory is allocated to ret->d, but it is insufficiently sized
leading to heap corruption. A similar issue exists in BN_dec2bn.
This could have security consequences if BN_hex2bn/BN_dec2bn is ever
called by user applications with very large untrusted hex/dec data. This is
anticipated to be a rare occurrence.
All OpenSSL internal usage of this function uses data that is not expected
to be untrusted, e.g. config file data or application command line
arguments. If user developed applications generate config file data based
on untrusted data then it is possible that this could also lead to security
consequences. This is also anticipated to be a rare.
Matt Caswell [Thu, 25 Feb 2016 13:09:46 +0000 (13:09 +0000)]
Fix memory issues in BIO_*printf functions
The internal |fmtstr| function used in processing a "%s" format string
in the BIO_*printf functions could overflow while calculating the length
of a string and cause an OOB read when printing very long strings.
Additionally the internal |doapr_outch| function can attempt to write to
an OOB memory location (at an offset from the NULL pointer) in the event of
a memory allocation failure. In 1.0.2 and below this could be caused where
the size of a buffer to be allocated is greater than INT_MAX. E.g. this
could be in processing a very long "%s" format string. Memory leaks can also
occur.
These issues will only occur on certain platforms where sizeof(size_t) >
sizeof(int). E.g. many 64 bit systems. The first issue may mask the second
issue dependent on compiler behaviour.
These problems could enable attacks where large amounts of untrusted data
is passed to the BIO_*printf functions. If applications use these functions
in this way then they could be vulnerable. OpenSSL itself uses these
functions when printing out human-readable dumps of ASN.1 data. Therefore
applications that print this data could be vulnerable if the data is from
untrusted sources. OpenSSL command line applications could also be
vulnerable where they print out ASN.1 data, or if untrusted data is passed
as command line arguments.
Libssl is not considered directly vulnerable. Additionally certificates etc
received via remote connections via libssl are also unlikely to be able to
trigger these issues because of message size limits enforced within libssl.
Emilia Kasper [Wed, 24 Feb 2016 11:59:59 +0000 (12:59 +0100)]
CVE-2016-0798: avoid memory leak in SRP
The SRP user database lookup method SRP_VBASE_get_by_user had confusing
memory management semantics; the returned pointer was sometimes newly
allocated, and sometimes owned by the callee. The calling code has no
way of distinguishing these two cases.
Specifically, SRP servers that configure a secret seed to hide valid
login information are vulnerable to a memory leak: an attacker
connecting with an invalid username can cause a memory leak of around
300 bytes per connection.
Servers that do not configure SRP, or configure SRP but do not configure
a seed are not vulnerable.
In Apache, the seed directive is known as SSLSRPUnknownUserSeed.
To mitigate the memory leak, the seed handling in SRP_VBASE_get_by_user
is now disabled even if the user has configured a seed.
Applications are advised to migrate to SRP_VBASE_get1_by_user. However,
note that OpenSSL makes no strong guarantees about the
indistinguishability of valid and invalid logins. In particular,
computations are currently not carried out in constant time.
David Woodhouse [Tue, 23 Feb 2016 14:00:03 +0000 (14:00 +0000)]
RT4175: Fix PKCS7_verify() regression with Authenticode signatures
This is a partial revert of commit c8491de39 ("GH354: Memory leak fixes"),
which was cherry-picked from commit 55500ea7c in OpenSSL 1.1.
That commit introduced a change in behaviour which is a regression for
software implementing Microsoft Authenticode — which requires a PKCS#7
signature to be validated against explicit external data, even though
it's a non-detached signature with its own embedded data.
The is fixed differently in OpenSSL 1.1 by commit 6b2ebe433 ("Add
PKCS7_NO_DUAL_CONTENT flag"), but that approach isn't viable in the
1.0.2 stable branch, so just comment the offending check back out again.
Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Tim Hudson <tjh@openssl.org>
Corinna Vinschen [Sat, 16 Jan 2016 18:36:15 +0000 (19:36 +0100)]
Don't strip object files on Cygwin
Building for the Cygwin distro requires to be able to build debuginfo
files. This in turn requires to build object files without stripping.
The stripping is performed by the next step after building which creates
the debuginfo files.
Andy Polyakov [Wed, 3 Feb 2016 17:21:00 +0000 (18:21 +0100)]
util/mk1mf.pl: use LINK_CMD instead of LINK variable.
Trouble is that LINK variable assignment in make-file interferes with
LINK environment variable, which can be used to modify Microsoft's
LINK.EXE behaviour.
Matt Caswell [Tue, 2 Feb 2016 10:05:43 +0000 (10:05 +0000)]
Handle SSL_shutdown while in init more appropriately #2
Previous commit f73c737c7 attempted to "fix" a problem with the way
SSL_shutdown() behaved whilst in mid-handshake. The original behaviour had
SSL_shutdown() return immediately having taken no action if called mid-
handshake with a return value of 1 (meaning everything was shutdown
successfully). In fact the shutdown has not been successful.
Commit f73c737c7 changed that to send a close_notify anyway and then
return. This seems to be causing some problems for some applications so
perhaps a better (much simpler) approach is revert to the previous
behaviour (no attempt at a shutdown), but return -1 (meaning the shutdown
was not successful).
This also fixes a bug where SSL_shutdown always returns 0 when shutdown
*very* early in the handshake (i.e. we are still using SSLv23_method).
Hubert Kario [Mon, 1 Feb 2016 16:14:34 +0000 (11:14 -0500)]
GH554: Improve pkeyutl doc
Signed-off-by: Rich Salz <rsalz@openssl.org> Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 53619f9f40740ae8b256998574758aa191635db8)
Signed-off-by: Rich Salz <rsalz@akamai.com> Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 8ab31975bacb9c907261088937d3aa4102e3af84)
Matt Caswell [Wed, 4 Nov 2015 17:30:22 +0000 (17:30 +0000)]
Fix bug in nistp224/256/521 where have_precompute_mult always returns 0
During precomputation if the group given is well known then we memcpy a
well known precomputation. However we go the wrong label in the code and
don't store the data properly. Consequently if we call have_precompute_mult
the data isn't there and we return 0.
Matt Caswell [Fri, 29 Jan 2016 09:38:06 +0000 (09:38 +0000)]
Correct value of DH_CHECK_PUBKEY_INVALID
A new return value for DH_check_pub_key was recently added:
DH_CHECK_PUBKEY_INVALID. As this is a flag which can be ORed with other
return values it should have been set to the value 4 not 3.
Matt Caswell [Thu, 17 Dec 2015 02:57:20 +0000 (02:57 +0000)]
Always generate DH keys for ephemeral DH cipher suites
Modified version of the commit ffaef3f15 in the master branch by Stephen
Henson. This makes the SSL_OP_SINGLE_DH_USE option a no-op and always
generates a new DH key for every handshake regardless.
Matt Caswell [Mon, 18 Jan 2016 11:31:58 +0000 (11:31 +0000)]
Prevent small subgroup attacks on DH/DHE
Historically OpenSSL only ever generated DH parameters based on "safe"
primes. More recently (in version 1.0.2) support was provided for
generating X9.42 style parameter files such as those required for RFC
5114 support. The primes used in such files may not be "safe". Where an
application is using DH configured with parameters based on primes that
are not "safe" then an attacker could use this fact to find a peer's
private DH exponent. This attack requires that the attacker complete
multiple handshakes in which the peer uses the same DH exponent.
A simple mitigation is to ensure that y^q (mod p) == 1
Matt Caswell [Mon, 7 Dec 2015 16:50:38 +0000 (16:50 +0000)]
Handle SSL_shutdown while in init more appropriately
Calling SSL_shutdown while in init previously gave a "1" response, meaning
everything was successfully closed down (even though it wasn't). Better is
to send our close_notify, but fail when trying to receive one.
The problem with doing a shutdown while in the middle of a handshake is
that once our close_notify is sent we shouldn't really do anything else
(including process handshake/CCS messages) until we've received a
close_notify back from the peer. However the peer might send a CCS before
acting on our close_notify - so we won't be able to read it because we're
not acting on CCS messages!
Richard Levitte [Tue, 19 Jan 2016 19:35:41 +0000 (20:35 +0100)]
Fix BSD -rpath parameter
For BSD systems, Configure adds a shared_ldflags including a reference
to the Makefile variable LIBRPATH, but since it must be passed down to
Makefile.shared, care must be taken so the value of LIBRPATH doesn't
get expanded too early, or it ends up giving an empty string.