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>

Also removes an extra initializer, the master branch has a extra field.

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

Backport of 98637bd3



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

backport of 3eb70c5e


shorter changes

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

Even though AVX support was added in GAS 2.19 vpclmulqdq was apparently
added in 2.20.

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

This reverts commit 6656ba71

.

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>

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>

RT#4284

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

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Kurt Roeckx <kurt@openssl.org>

This is a partial revert of commit c8491de3 ("GH354: Memory leak fixes"),
which was cherry-picked from commit 55500ea7 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 6b2ebe43

 ("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>

  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.

Signed-off-by: Corinna Vinschen <vinschen@redhat.com>

(cherry picked from commit 42b8f142

)

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

In response to RT#4326

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

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>

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

In backporting from master one modification was mistreated.

RT#4210

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

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

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

RT#4210

(1.0.2-specific adaptation of 7687f525

)

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

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)

Change the default keysize to 2048 bits, and the minimum to 512 bits.

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

RT#3885

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

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

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

Previous commit f73c737c 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 f73c737c

 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).

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

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

Also in X509_verify_cert() avoid using "i" not only as a loop
counter, but also as a trust outcome and as an error ordinal.

Finally, make sure that all "goto end" jumps return an error, with
"end" renamed to "err" accordingly.

[ The 1.1.0 version of X509_verify_cert() is major rewrite,
  which addresses these issues in a more systemic way. ]

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

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

RT: #4288, MR: #1831
(cherry picked from commit df057ea6)

Also fix option processing in pkeyutl to allow use of (formerly)
"out-of-order" switches that were needless implementation limitations.

RT2018

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

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

Signed-off-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 53619f9f)

Signed-off-by: Rich Salz <rsalz@akamai.com>
Reviewed-by: Dr. Stephen Henson <steve@openssl.org>
(cherry picked from commit 8ab31975)

Can't hurt and seems to prevent problems from some over-aggressive
(LTO?) compilers.

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

Reviewed-by: Andy Polyakov <appro@openssl.org>

Add tests for have_precompute_mult for the optimised curves (nistp224,
nistp256 and nistp521) if present

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

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.

RT#3600

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

The function DH_check_pub_key() was missing some return value checks in
some calls to BN functions.

RT#4278

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

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.

RT#4278

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

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

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