Under certain circumstances, the libcrypto init code would loop,
causing a deadlock.  This would typically happen if something in
ossl_init_base() caused an OpenSSL error, and the error stack routines
would recurse into the init code before the flag that ossl_init_base()
had been run was checked.

This change makes sure ossl_init_base isn't run once more of the base
is initiated.

Thanks to Dmitry Kostjuchenko for the idea.

Fixes Github issue #1899

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1922)
(cherry picked from commit b7a7f39a)

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

prio openssl 1.1.0 seed_len < q was accepted and the seed argument was
then ignored. Now DSA_generate_parameters_ex() returns an error in such
a case but no error string.

Signed-off-by: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1657)
(cherry picked from commit af547412)

This reverts commit edc18749

.

The proposed fix is incorrect. It marks the "run_once" code as having
finished before it has. The intended semantics of run_once is that no
threads should proceed until the code has run exactly once. With this
change the "second" thread will think the run_once code has already been
run and will continue, even though it is still in progress. This could
result in a crash or other incorrect behaviour.

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

Fixed deadlock in CRYPTO_THREAD_run_once() if call to init() is causing
a recursive call to CRYPTO_THREAD_run_once() again that is causing a hot
deadloop inside do { } while (result == ONCE_ININIT); section.

CLA: trivial
Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1913)

(cherry picked from commit 349d1cfd)

Avoid a memory alignment issue.

Signed-off-by: Matthias Kraft <Matthias.Kraft@softwareag.com>
CLA: trivial
Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1650)

(cherry picked from commit af5883fe)

Reviewed-by: Matt Caswell <matt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1837)
(cherry picked from commit a22f9c84)

Replace the 'SSL' broken link with SSL_CTX_set_security_level which seems not being referenced from elsewhere

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1898)
(cherry picked from commit e330f55d)

CLA: trivial

Reviewed-by: Andy Polyakov <appro@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1909)
(cherry picked from commit 625b9d6b)

llvm's ubsan reported:
runtime error: negation of -9223372036854775808 cannot be represented in
type 'int64_t' (aka 'long'); cast to an unsigned type to negate this
value to itself

Found using libfuzzer

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

GH: #1908
(cherry picked from commit e80f3b6a)

In order to minimize dependency on assembler version a number of
post-SSE2 instructions are encoded manually. But in order to simplify
the procedure only register operands are considered. Non-register
operands are passed down to assembler. Module in question uses pshufb
with memory operands, and old [GNU] assembler can't handle it.
Fortunately in this case it's possible skip just the problematic
segment without skipping SSSE3 support altogether.

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

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

When configured no-dso, there are no DSO_{whatever} macros defined.
Therefore, before checking those, you have to check if OPENSSL_NO_DSO
is defined.

Reviewed-by: Matt Caswell <matt@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1902)
(cherry picked from commit 6e290a25)

Apparently, pod2html doesn't add ".html" at the end of links, making
them useless, so we need to fix that

With thanks for the report to Michel <michel.sales@free.fr>

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1897)

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

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

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

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

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

This is done by taking one vector, "corrupting" last bit of the
tag value and verifying that decrypt fails.

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

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

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

Don't set choice selector on parse failure: this can pass unexpected
values to the choice callback. Instead free up partial structure
directly.

CVE-2016-7053

Thanks to Tyler Nighswander of ForAllSecure for reporting this issue.

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

The offset to the memory to clear was incorrect, causing a heap buffer
overflow.

CVE-2016-7054

Thanks to Robert Święcki for reporting this

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

Some of stone-age assembler can't cope with r0 in address. It's actually
sensible thing to do, because r0 is shunted to 0 in address arithmetic
and by refusing r0 assembler effectively makes you understand that.

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

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

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

Skip the test if the value after ":" is a disabled algorithm, rather
than failing it

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

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

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1859)

(cherry picked from commit 7bb37cb5)

For consistency, it's better to use the perl that was specified to
Configure last time it was called.

Use case:

perl v5.8.8 was first along $PATH, perl v5.22.2 was available and
specified as: PERL=/opt/local/bin/perl ./config.  When make wanted to
reconfigure and called './Configure reconf', configuration broke down,
complaining about a perl that's too old.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1884)
(cherry picked from commit 12ccb021)

BN_RECP_CTX_new direclty use bn_init to avoid twice memset calls

Reviewed-by: Kurt Roeckx <kurt@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1879)
(cherry picked from commit 318447bc)

Thanks to Falko Strenzke for bringing this to our attention.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1882)
(cherry picked from commit e5e71f28)

libssl, not libddl.

Reviewed-by: Andy Polyakov <appro@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1871)
(cherry picked from commit b77b6127)

and fix documentation.

Reviewed-by: Tim Hudson <tjh@openssl.org>
Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/1634)
(cherry picked from commit 7cb1ecec)

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

GH: #1834
(cherry picked from commit 27ed73a9)

MD5/SHA1 and MDC-2 have special-case logic beyond the generic DigestInfo
wrapping. Test that each of these works, including hash and length
mismatches (both input and signature). Also add VerifyRecover tests. It
appears 5824cc29

 added support for
VerifyRecover, but forgot to add the test data.

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

GH: #1474
(cherry picked from commit f3205557)

PKCS #1 v2.0 is the name of a document which specifies an algorithm
RSASSA-PKCS1-v1_5, often referred to as "PKCS #1 v1.5" after an earlier
document which specified it. This gets further confusing because the
document PKCS #1 v2.1 specifies two signature algorithms,
RSASSA-PKCS1-v1_5 and RSASSA-PSS. RSA_sign implements RSASSA-PKCS1-v1_5.

Refer to the document using the RFC number which is easier to find
anyway, and refer to the algorithm by its name.

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

GH: #1474
(cherry picked from commit aa90ca11)

RFC 3447, section 8.2.2, steps 3 and 4 states that verifiers must encode
the DigestInfo struct and then compare the result against the public key
operation result. This implies that one and only one encoding is legal.

OpenSSL instead parses with crypto/asn1, then checks that the encoding
round-trips, and allows some variations for the parameter. Sufficient
laxness in this area can allow signature forgeries, as described in
https://www.imperialviolet.org/2014/09/26/pkcs1.html

Although there aren't known attacks against OpenSSL's current scheme,
this change makes OpenSSL implement the algorithm as specified. This
avoids the uncertainty and, more importantly, helps grow a healthy
ecosystem. Laxness beyond the spec, particularly in implementations
which enjoy wide use, risks harm to the ecosystem for all. A signature
producer which only tests against OpenSSL may not notice bugs and
accidentally become widely deployed. Thus implementations have a
responsibility to honor the specification as tightly as is practical.

In some cases, the damage is permanent and the spec deviation and
security risk becomes a tax all implementors must forever pay, but not
here. Both BoringSSL and Go successfully implemented and deployed
RSASSA-PKCS1-v1_5 as specified since their respective beginnings, so
this change should be compatible enough to pin down in future OpenSSL
releases.

See also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00



As a bonus, by not having to deal with sign/verify differences, this
version is also somewhat clearer. It also more consistently enforces
digest lengths in the verify_recover codepath. The NID_md5_sha1 codepath
wasn't quite doing this right.

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

GH: #1474
(cherry picked from commit 608a0264)

This partially reverts commit c636c1c4

. It also tweaks the documentation
and comments in this area. On the client side the documented interface for
SSL_CTX_set_verify()/SSL_set_verify() is that setting the flag
SSL_VERIFY_PEER causes verfication of the server certificate to take place.
Previously what was implemented was that if *any* flag was set then
verification would take place. The above commit improved the semantics to
be as per the documented interface.

However, we have had a report of at least one application where an
application was incorrectly using the interface and used *only*
SSL_VERIFY_FAIL_IF_NO_PEER_CERT on the client side. In OpenSSL prior to
the above commit this still caused verification of the server certificate
to take place. After this commit the application silently failed to verify
the server certificate.

Ideally SSL_CTX_set_verify()/SSL_set_verify() could be modified to indicate
if invalid flags were being used. However these are void functions!

The simplest short term solution is to revert to the previous behaviour
which at least means we "fail closed" rather than "fail open".

Thanks to Cory Benfield for reporting this issue.

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