[Backport from master]

CVE-2016-0702

Reviewed-by: Richard Levitte <levitte@openssl.org>

Performance penalty varies from platform to platform, and even
key length. For rsa2048 sign it was observed to reach almost 10%.

CVE-2016-0702

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Emilia Käsper <emilia@openssl.org>

Reviewed-by: Emilia Käsper <emilia@openssl.org>

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.

Mitigation for CVE-2016-0800

Reviewed-by: Emilia Käsper <emilia@openssl.org>

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.

Issue reported by Guido Vranken.

CVE-2016-0797

Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit c1753084)

This reverts commit 23a58779

.

This broke existing engines that didn't properly implement the sign and verify
functions.

Reviewed-by: Richard Levitte <levitte@openssl.org>

MR: #2077

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.

CVE-2016-0799

Issue reported by Guido Vranken.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(cherry picked from commit 578b956f)

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.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>
(cherry picked from commit 04f2a0b5)

Fix double free bug when parsing malformed DSA private keys.

Thanks to Adam Langley (Google/BoringSSL) for discovering this bug using
libFuzzer.

CVE-2016-0705

Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit 6c88c71b)

It's never problem if CRYPTO_ctr128_encrypt is called from EVP, because
buffer in question is always aligned within EVP_CIPHER_CTX structure.

RT#4218

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 5e4bbeb4)

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.

RT#4289

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit d44bb1c3)

Resolved conflicts:
	util/pl/VC-32.pl

(cherry picked from commit 0fffd522)

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 740b2b9a)

Reviewed-by: Viktor Dukhovni <openssl-users@dukhovni.org>
(cherry picked from commit 2b0c11a6)

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 41a28cb2)

Reviewed-by: Richard Levitte <levitte@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

This solves an earlier cherry-pick mistake.

Reviewed-by: Matt Caswell <matt@openssl.org>

Reviewed-by: Richard Levitte <levitte@openssl.org>

Update CHANGES and NEWS with details of the issues fixed in the forthcoming
release.

Reviewed-by: Rich Salz <rsalz@openssl.org>

Based on patch by: Nimrod Aviram <nimrod.aviram@gmail.com>

CVE-2015-3197

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>

Modified version of the commit ffaef3f1

 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.

This is a follow on from CVE-2016-0701. This branch is not impacted by
that CVE because it does not support X9.42 style parameters. It is still
possible to generate parameters based on primes that are not "safe",
although by default OpenSSL does not do this. The documentation does
sign post that using such parameters is unsafe if the private DH key is
reused. However to avoid accidental problems or future attacks this commit
has been backported to this branch.

Issue reported by Antonio Sanso

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>

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.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(cherry picked from commit c64879d3)

RT#4080

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 02f70372)

Reviewed-by: Rich Salz <rsalz@openssl.org>

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(cherry picked from commit 9aa00b18)

Conflicts:
	apps/x509.c

Reviewed-by: Viktor Dukhovni <openssl-users@dukhovni.org>

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 1918e01c)

Reviewed-by: Dr. Stephen Henson <steve@openssl.org>

Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 41977c53)

Describe the usage of the OCSP callback functions on both the client and
the server side.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(cherry picked from commit c52c3b5e)

It makes no sense to call the OCSP status callback if we are resuming a
session because no certificates will be sent.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(cherry picked from commit 0ac62399)

If a server sends the status_request extension then it may choose
to send the CertificateStatus message. However this is optional.
We were treating it as mandatory and the connection was failing.

Thanks to BoringSSL for reporting this issue.

RT#4120

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
(cherry picked from commit 905943af)

Found by clang scan-build.

Signed-off-by: Kurt Roeckx <kurt@roeckx.be>
Reviewed-by: Richard Levitte <levitte@openssl.org>

RT: #4184, MR: #1496
(cherry picked from commit 679d8751)

Reviewed-by: Richard Levitte <levitte@openssl.org>
(cherry picked from commit 6656ba71)

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 17592f32)

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 6d97060e)

No dummy arguments.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(cherry picked from commit 7eb51251)