Avoid overflow in MDC2_Update()

Thanks to Shi Lei for reporting this issue.

CVE-2016-6303

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

SWEET32 (CVE-2016-2183): Move DES from HIGH to MEDIUM

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Emilia Käsper <emilia@openssl.org>
(cherry picked from commit 0fff5065884d5ac61123a604bbcee30a53c808ff)

Sanity check ticket length.

If a ticket callback changes the HMAC digest to SHA512 the existing
sanity checks are not sufficient and an attacker could perform a DoS
attack with a malformed ticket. Add additional checks based on
HMAC size.

Thanks to Shi Lei for reporting this bug.

CVE-2016-6302

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

Fix overflow check in BN_bn2dec()

Fix an off by one error in the overflow check added by 07bed46f332fc
("Check for errors in BN_bn2dec()").

Reviewed-by: Stephen Henson <steve@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 099e2968ed3c7d256cda048995626664082b1b30)

Prevent DTLS Finished message injection

Follow on from CVE-2016-2179

The investigation and analysis of CVE-2016-2179 highlighted a related flaw.

This commit fixes a security "near miss" in the buffered message handling
code. Ultimately this is not currently believed to be exploitable due to
the reasons outlined below, and therefore there is no CVE for this on its
own.

The issue this commit fixes is a MITM attack where the attacker can inject
a Finished message into the handshake. In the description below it is
assumed that the attacker injects the Finished message for the server to
receive it. The attack could work equally well the other way around (i.e
where the client receives the injected Finished message).

The MITM requires the following capabilities:
- The ability to manipulate the MTU that the client selects such that it
is small enough for the client to fragment Finished messages.
- The ability to selectively drop and modify records sent from the client
- The ability to inject its own records and send them to the server

The MITM forces the client to select a small MTU such that the client
will fragment the Finished message. Ideally for the attacker the first
fragment will contain all but the last byte of the Finished message,
with the second fragment containing the final byte.

During the handshake and prior to the client sending the CCS the MITM
injects a plaintext Finished message fragment to the server containing
all but the final byte of the Finished message. The message sequence
number should be the one expected to be used for the real Finished message.

OpenSSL will recognise that the received fragment is for the future and
will buffer it for later use.

After the client sends the CCS it then sends its own Finished message in
two fragments. The MITM causes the first of these fragments to be
dropped. The OpenSSL server will then receive the second of the fragments
and reassemble the complete Finished message consisting of the MITM
fragment and the final byte from the real client.

The advantage to the attacker in injecting a Finished message is that
this provides the capability to modify other handshake messages (e.g.
the ClientHello) undetected. A difficulty for the attacker is knowing in
advance what impact any of those changes might have on the final byte of
the handshake hash that is going to be sent in the "real" Finished
message. In the worst case for the attacker this means that only 1 in
256 of such injection attempts will succeed.

It may be possible in some situations for the attacker to improve this such
that all attempts succeed. For example if the handshake includes client
authentication then the final message flight sent by the client will
include a Certificate. Certificates are ASN.1 objects where the signed
portion is DER encoded. The non-signed portion could be BER encoded and so
the attacker could re-encode the certificate such that the hash for the
whole handshake comes to a different value. The certificate re-encoding
would not be detectable because only the non-signed portion is changed. As
this is the final flight of messages sent from the client the attacker
knows what the complete hanshake hash value will be that the client will
send - and therefore knows what the final byte will be. Through a process
of trial and error the attacker can re-encode the certificate until the
modified handhshake also has a hash with the same final byte. This means
that when the Finished message is verified by the server it will be
correct in all cases.

In practice the MITM would need to be able to perform the same attack
against both the client and the server. If the attack is only performed
against the server (say) then the server will not detect the modified
handshake, but the client will and will abort the connection.
Fortunately, although OpenSSL is vulnerable to Finished message
injection, it is not vulnerable if *both* client and server are OpenSSL.
The reason is that OpenSSL has a hard "floor" for a minimum MTU size
that it will never go below. This minimum means that a Finished message
will never be sent in a fragmented form and therefore the MITM does not
have one of its pre-requisites. Therefore this could only be exploited
if using OpenSSL and some other DTLS peer that had its own and separate
Finished message injection flaw.

The fix is to ensure buffered messages are cleared on epoch change.

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

Fix DTLS buffered message DoS attack

DTLS can handle out of order record delivery. Additionally since
handshake messages can be bigger than will fit into a single packet, the
messages can be fragmented across multiple records (as with normal TLS).
That means that the messages can arrive mixed up, and we have to
reassemble them. We keep a queue of buffered messages that are "from the
future", i.e. messages we're not ready to deal with yet but have arrived
early. The messages held there may not be full yet - they could be one
or more fragments that are still in the process of being reassembled.

The code assumes that we will eventually complete the reassembly and
when that occurs the complete message is removed from the queue at the
point that we need to use it.

However, DTLS is also tolerant of packet loss. To get around that DTLS
messages can be retransmitted. If we receive a full (non-fragmented)
message from the peer after previously having received a fragment of
that message, then we ignore the message in the queue and just use the
non-fragmented version. At that point the queued message will never get
removed.

Additionally the peer could send "future" messages that we never get to
in order to complete the handshake. Each message has a sequence number
(starting from 0). We will accept a message fragment for the current
message sequence number, or for any sequence up to 10 into the future.
However if the Finished message has a sequence number of 2, anything
greater than that in the queue is just left there.

So, in those two ways we can end up with "orphaned" data in the queue
that will never get removed - except when the connection is closed. At
that point all the queues are flushed.

An attacker could seek to exploit this by filling up the queues with
lots of large messages that are never going to be used in order to
attempt a DoS by memory exhaustion.

I will assume that we are only concerned with servers here. It does not
seem reasonable to be concerned about a memory exhaustion attack on a
client. They are unlikely to process enough connections for this to be
an issue.

A "long" handshake with many messages might be 5 messages long (in the
incoming direction), e.g. ClientHello, Certificate, ClientKeyExchange,
CertificateVerify, Finished. So this would be message sequence numbers 0
to 4. Additionally we can buffer up to 10 messages in the future.
Therefore the maximum number of messages that an attacker could send
that could get orphaned would typically be 15.

The maximum size that a DTLS message is allowed to be is defined by
max_cert_list, which by default is 100k. Therefore the maximum amount of
"orphaned" memory per connection is 1500k.

Message sequence numbers get reset after the Finished message, so
renegotiation will not extend the maximum number of messages that can be
orphaned per connection.

As noted above, the queues do get cleared when the connection is closed.
Therefore in order to mount an effective attack, an attacker would have
to open many simultaneous connections.

Issue reported by Quan Luo.

CVE-2016-2179

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

Fix off by 1 in ASN1_STRING_set()

Reviewed-by: Rich Salz <rsalz@openssl.org>
MR: #3176
(cherry picked from commit a73be798ced572a988d455d961a2387f6eccb549)

RT3940: For now, just document the issue.

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

Update function error code

A function error code needed updating due to merge issues.

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

Fix DTLS replay protection

The DTLS implementation provides some protection against replay attacks
in accordance with RFC6347 section 4.1.2.6.

A sliding "window" of valid record sequence numbers is maintained with
the "right" hand edge of the window set to the highest sequence number we
have received so far. Records that arrive that are off the "left" hand
edge of the window are rejected. Records within the window are checked
against a list of records received so far. If we already received it then
we also reject the new record.

If we have not already received the record, or the sequence number is off
the right hand edge of the window then we verify the MAC of the record.
If MAC verification fails then we discard the record. Otherwise we mark
the record as received. If the sequence number was off the right hand edge
of the window, then we slide the window along so that the right hand edge
is in line with the newly received sequence number.

Records may arrive for future epochs, i.e. a record from after a CCS being
sent, can arrive before the CCS does if the packets get re-ordered. As we
have not yet received the CCS we are not yet in a position to decrypt or
validate the MAC of those records. OpenSSL places those records on an
unprocessed records queue. It additionally updates the window immediately,
even though we have not yet verified the MAC. This will only occur if
currently in a handshake/renegotiation.

This could be exploited by an attacker by sending a record for the next
epoch (which does not have to decrypt or have a valid MAC), with a very
large sequence number. This means the right hand edge of the window is
moved very far to the right, and all subsequent legitimate packets are
dropped causing a denial of service.

A similar effect can be achieved during the initial handshake. In this
case there is no MAC key negotiated yet. Therefore an attacker can send a
message for the current epoch with a very large sequence number. The code
will process the record as normal. If the hanshake message sequence number
(as opposed to the record sequence number that we have been talking about
so far) is in the future then the injected message is bufferred to be
handled later, but the window is still updated. Therefore all subsequent
legitimate handshake records are dropped. This aspect is not considered a
security issue because there are many ways for an attacker to disrupt the
initial handshake and prevent it from completing successfully (e.g.
injection of a handshake message will cause the Finished MAC to fail and
the handshake to be aborted). This issue comes about as a result of trying
to do replay protection, but having no integrity mechanism in place yet.
Does it even make sense to have replay protection in epoch 0? That
issue isn't addressed here though.

This addressed an OCAP Audit issue.

CVE-2016-2181

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

Fix DTLS unprocessed records bug

During a DTLS handshake we may get records destined for the next epoch
arrive before we have processed the CCS. In that case we can't decrypt or
verify the record yet, so we buffer it for later use. When we do receive
the CCS we work through the queue of unprocessed records and process them.

Unfortunately the act of processing wipes out any existing packet data
that we were still working through. This includes any records from the new
epoch that were in the same packet as the CCS. We should only process the
buffered records if we've not got any data left.

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

make update to have PEM_R_HEADER_TOO_LONG defined

(cherry picked from commit a1be17a72f6e0fe98275dc113cddd799bf55df44)

Conflicts:
crypto/pem/pem_err.c

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

Limit reads in do_b2i_bio()

Apply a limit to the maximum blob length which can be read in do_d2i_bio()
to avoid excessive allocation.

Thanks to Shi Lei for reporting this.

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

Check for errors in BN_bn2dec()

If an oversize BIGNUM is presented to BN_bn2dec() it can cause
BN_div_word() to fail and not reduce the value of 't' resulting
in OOB writes to the bn_data buffer and eventually crashing.

Fix by checking return value of BN_div_word() and checking writes
don't overflow buffer.

Thanks to Shi Lei for reporting this bug.

CVE-2016-2182

Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 07bed46f332fce8c1d157689a2cdf915a982ae34)

Conflicts:
crypto/bn/bn_print.c

Check for errors in a2d_ASN1_OBJECT()

Check for error return in BN_div_word().

Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 8b9afbc0fc7f8be0049d389d34d9416fa377e2aa)

Sanity check input length in OPENSSL_uni2asc().

Thanks to Hanno Böck for reporting this bug.

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

Conflicts:
crypto/pkcs12/p12_utl.c

Leak fixes.

Fix error path leaks in a2i_ASN1_STRING(), a2i_ASN1_INTEGER() and
a2i_ASN1_ENUMERATED().

Thanks to Shi Lei for reporting these issues.

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

Return error when trying to print invalid ASN1 integer

GH: #1322

Reviewed-by: Rich Salz <rsalz@openssl.org>
Reviewed-by: Stephen Henson <steve@openssl.org>
(cherry picked from commit 32baafb2f6fb2a424824df08232d86765f554880)

Limit recursion depth in old d2i_ASN1_bytes function

Thanks to Shi Lei for reporting this bug.

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

Check for overflows in i2d_ASN1_SET()

Thanks to Shi Lei for reporting this issue.

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

Calculate sequence length properly.

Use correct length in old ASN.1 indefinite length sequence decoder
(only used by SSL_SESSION).

This bug was discovered by Hanno Böck using libfuzzer.

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

include <limits.h>

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

Check for overflows in ASN1_object_size().

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

Check for overlows and error return from ASN1_object_size()

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

Fix OOB read in TS_OBJ_print_bio().

TS_OBJ_print_bio() misuses OBJ_txt2obj: it should print the result
as a null terminated buffer. The length value returned is the total
length the complete text reprsentation would need not the amount of
data written.

CVE-2016-2180

Thanks to Shi Lei for reporting this bug.

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

Convert memset calls to OPENSSL_cleanse

Ensure things really do get cleared when we intend them to.

Addresses an OCAP Audit issue.

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

Allow proxy certs to be present when verifying a chain

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

Fix proxy certificate pathlength verification

While travelling up the certificate chain, the internal
proxy_path_length must be updated with the pCPathLengthConstraint
value, or verification will not work properly.  This corresponds to
RFC 3820, 4.1.4 (a).

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

Check that the subject name in a proxy cert complies to RFC 3820

The subject name MUST be the same as the issuer name, with a single CN
entry added.

RT#1852

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

Change usage of RAND_pseudo_bytes to RAND_bytes

RAND_pseudo_bytes() allows random data to be returned even in low entropy
conditions. Sometimes this is ok. Many times it is not. For the avoidance
of any doubt, replace existing usage of RAND_pseudo_bytes() with
RAND_bytes().

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

More fix DSA, preserve BN_FLG_CONSTTIME

The previous "fix" still left "k" exposed to constant time problems in
the later BN_mod_inverse() call. Ensure both k and kq have the
BN_FLG_CONSTTIME flag set at the earliest opportunity after creation.

CVE-2016-2178

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

Fix DSA, preserve BN_FLG_CONSTTIME

Operations in the DSA signing algorithm should run in constant time in
order to avoid side channel attacks. A flaw in the OpenSSL DSA
implementation means that a non-constant time codepath is followed for
certain operations. This has been demonstrated through a cache-timing
attack to be sufficient for an attacker to recover the private DSA key.

CVE-2016-2178

Reviewed-by: Richard Levitte <levitte@openssl.org>
Reviewed-by: Matt Caswell <matt@openssl.org>
(cherry picked from commit 621eaf49a289bfac26d4cbcdb7396e796784c534)

Update CONTRIBUTING

Fix typos and clarify a few things in the CONTRIBUTING file.

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

Avoid some undefined pointer arithmetic

A common idiom in the codebase is:

if (p + len > limit)
{
    return; /* Too long */
}

Where "p" points to some malloc'd data of SIZE bytes and
limit == p + SIZE

"len" here could be from some externally supplied data (e.g. from a TLS
message).

The rules of C pointer arithmetic are such that "p + len" is only well
defined where len <= SIZE. Therefore the above idiom is actually
undefined behaviour.

For example this could cause problems if some malloc implementation
provides an address for "p" such that "p + len" actually overflows for
values of len that are too big and therefore p + len < limit!

Issue reported by Guido Vranken.

CVE-2016-2177

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

Ensure verify error is set when X509_verify_cert() fails

Set ctx->error = X509_V_ERR_OUT_OF_MEM when verificaiton cannot
continue due to malloc failure.  Similarly for issuer lookup failures
and caller errors (bad parameters or invalid state).

Also, when X509_verify_cert() returns <= 0 make sure that the
verification status does not remain X509_V_OK, as a last resort set
it it to X509_V_ERR_UNSPECIFIED, just in case some code path returns
an error without setting an appropriate value of ctx->error.

Add new and some missing error codes to X509 error -> SSL alert switch.

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

Clarify negative return from X509_verify_cert()

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

Fix error return value in SRP functions

The functions SRP_Calc_client_key() and SRP_Calc_server_key() were
incorrectly returning a valid pointer in the event of error.

Issue reported by Yuan Jochen Kang

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

Check that the obtained public key is valid

In the X509 app check that the obtained public key is valid before we
attempt to use it.

Issue reported by Yuan Jochen Kang.

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

Recommend GH over RT, per team vote.

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

Update S/MIME certificates.

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

Only call FIPS_update, FIPS_final in FIPS mode.

RT#3826

Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 2b4825d0bb6057e44717007a54797df72babdb7e)

Constify PKCS12_newpass()

PR#4449

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

Tidy up PKCS12_newpass() fix memory leaks.

PR#4466

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

Only set CMS parameter when encrypting

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

Use default ASN.1 for SEED.

The default ASN.1 handling can be used for SEED. This also makes
CMS work with SEED.

PR#4504

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

Always try to set ASN.1 parameters for CMS.

Try to set the ASN.1 parameters for CMS encryption even if the IV
length is zero as the underlying cipher should still set the type.

This will correctly result in errors if an attempt is made to use
an unsupported cipher type.

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

Conflicts:
crypto/cms/cms_enc.c

Fix name length limit check.

The name length limit check in x509_name_ex_d2i() includes
the containing structure as well as the actual X509_NAME. This will
cause large CRLs to be rejected.

Fix by limiting the length passed to ASN1_item_ex_d2i() which will
then return an error if the passed X509_NAME exceeds the length.

RT#4531

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

Fix double free in d2i_PrivateKey().

RT#4527

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

add documentation

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

Prepare for 1.0.1u-dev

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

Prepare for 1.0.1t release

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

make update

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

Update CHANGES and NEWS for the new release

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

Fix ASN1_INTEGER handling.

Only treat an ASN1_ANY type as an integer if it has the V_ASN1_INTEGER
tag: V_ASN1_NEG_INTEGER is an internal only value which is never used
for on the wire encoding.

Thanks to David Benjamin <davidben@google.com> for reporting this bug.

This was found using libFuzzer.

RT#4364 (part)CVE-2016-2108.

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

Check that we have enough padding characters.

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

MR: #2572

Remove some documentation for functions not in 1.0.x

A few functions in the recently added EVP_EncodeInit docs don't apply to
the 1.0.x branches.

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

Add documentation for EVP_EncodeInit() and similar functions

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

Ensure EVP_EncodeUpdate handles an output length that is too long

With the EVP_EncodeUpdate function it is the caller's responsibility to
determine how big the output buffer should be. The function writes the
amount actually used to |*outl|. However this could go negative with a
sufficiently large value for |inl|. We add a check for this error
condition.

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

Avoid overflow in EVP_EncodeUpdate

An overflow can occur in the EVP_EncodeUpdate function which is used for
Base64 encoding of binary data. If an attacker is able to supply very large
amounts of input data then a length check can overflow resulting in a heap
corruption. Due to the very large amounts of data involved this will most
likely result in a crash.

Internally to OpenSSL the EVP_EncodeUpdate function is primarly used by the
PEM_write_bio* family of functions. These are mainly used within the
OpenSSL command line applications, so any application which processes
data from an untrusted source and outputs it as a PEM file should be
considered vulnerable to this issue.

User applications that call these APIs directly with large amounts of
untrusted data may also be vulnerable.

Issue reported by Guido Vranken.

CVE-2016-2105

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

Prevent EBCDIC overread for very long strings

ASN1 Strings that are over 1024 bytes can cause an overread in
applications using the X509_NAME_oneline() function on EBCDIC systems.
This could result in arbitrary stack data being returned in the buffer.

Issue reported by Guido Vranken.

CVE-2016-2176

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

Fix encrypt overflow

An overflow can occur in the EVP_EncryptUpdate function. If an attacker is
able to supply very large amounts of input data after a previous call to
EVP_EncryptUpdate with a partial block then a length check can overflow
resulting in a heap corruption.

Following an analysis of all OpenSSL internal usage of the
EVP_EncryptUpdate function all usage is one of two forms.

The first form is like this:
EVP_EncryptInit()
EVP_EncryptUpdate()

i.e. where the EVP_EncryptUpdate() call is known to be the first called
function after an EVP_EncryptInit(), and therefore that specific call
must be safe.

The second form is where the length passed to EVP_EncryptUpdate() can be
seen from the code to be some small value and therefore there is no
possibility of an overflow.

Since all instances are one of these two forms, I believe that there can
be no overflows in internal code due to this problem.

It should be noted that EVP_DecryptUpdate() can call EVP_EncryptUpdate()
in certain code paths. Also EVP_CipherUpdate() is a synonym for
EVP_EncryptUpdate(). Therefore I have checked all instances of these
calls too, and came to the same conclusion, i.e. there are no instances
in internal usage where an overflow could occur.

This could still represent a security issue for end user code that calls
this function directly.

CVE-2016-2106

Issue reported by Guido Vranken.

Reviewed-by: Tim Hudson <tjh@openssl.org>
(cherry picked from commit 3f3582139fbb259a1c3cbb0a25236500a409bf26)

Fix i2d_X509_AUX: pp can be NULL.

Reported by David Benjamin

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

Don't free ret->data if malloc fails.

Issue reported by Guido Vranken.

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

Add checks to X509_NAME_oneline()

Sanity check field lengths and sums to avoid potential overflows and reject
excessively large X509_NAME structures.

Issue reported by Guido Vranken.

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

Conflicts:
crypto/x509/x509.h
crypto/x509/x509_err.c

Sanity check buffer length.

Reject zero length buffers passed to X509_NAME_onelne().

Issue reported by Guido Vranken.

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

Add size limit to X509_NAME structure.

This adds an explicit limit to the size of an X509_NAME structure. Some
part of OpenSSL (e.g. TLS) already effectively limit the size due to
restrictions on certificate size.

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

Reject inappropriate private key encryption ciphers.

The traditional private key encryption algorithm doesn't function
properly if the IV length of the cipher is zero. These ciphers
(e.g. ECB mode) are not suitable for private key encryption
anyway.

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

Ensure we check i2d_X509 return val

The i2d_X509() function can return a negative value on error. Therefore
we should make sure we check it.

Issue reported by Yuan Jochen Kang.

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

Fix a signed/unsigned warning

This causes a compilation failure when using --strict-warnings in 1.0.2
and 1.0.1

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

Fix NULL deref in apps/pkcs7

Thanks to Brian Carpenter for finding and reporting this.

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

Fix buffer overrun in ASN1_parse().

Backport of commits:

        79c7f74d6cefd5d32fa20e69195ad3de834ce065
bdcd660e33710079b495cf5cc6a1aaa5d2dcd317

from master.

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

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.

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

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>
(cherry picked from commit ec66c8c98881186abbb4a7ddd6617970f1ee27a7)

Fix FIPS SSLv2 test

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

Fix the no-comp option for Windows

no-comp on Windows was not actually suppressing compilation of the code,
although it was suppressing its use.

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

Add a check for a failed malloc

Ensure we check for a NULL return from OPENSSL_malloc

Issue reported by Guido Vranken.

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

Ensure that memory allocated for the ticket is freed

If a call to EVP_DecryptUpdate fails then a memory leak could occur.
Ensure that the memory is freed appropriately.

Issue reported by Guido Vranken.

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

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.

Issue reported by Guido Vranken.

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

Add no-ssl2-method

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
MR: #2341
(cherry picked from commit 4256957570a233ed4e9840353e95e623dfd62086)

expose SSLv2 method prototypes

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

Retain SSLv2 methods as functions that return NULL

This improves ABI compatibility when symbol resolution is not lazy.

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

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

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

Resolved conflicts:
crypto/bn/asm/x86_64-mont.pl
crypto/bn/asm/x86_64-mont5.pl

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

Remove LOW from the default

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

Don't shift serial number into sign bit

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

Sanity check PVK file fields.

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.

Issue reported by Guido Vranken.

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

Prepare for 1.0.1t-dev

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

Prepare for 1.0.1s release

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

make update

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

Ensure mk1mf.pl is aware of no-weak-ssl-ciphers option

Update mk1mf.pl to properly handle no-weak-ssl-ciphers

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

Update CHANGES and NEWS for new release

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

perlasm/x86_64-xlate.pl: handle inter-bank movd.

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

crypto/bn/x86_64-mont5.pl: constant-time gather procedure.

[Backport from master]

CVE-2016-0702

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

bn/bn_exp.c: constant-time MOD_EXP_CTIME_COPY_FROM_PREBUF.

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>

Disable EXPORT and LOW SSLv3+ ciphers by default

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

Bring SSL method documentation up to date

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

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.

Mitigation for CVE-2016-0800

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

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.

Issue reported by Guido Vranken.

CVE-2016-0797

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

Revert "Don't check RSA_FLAG_SIGN_VER."

This reverts commit 23a58779f53a9060c823d00d76b3070cad61d9a3.

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

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

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.

CVE-2016-0799

Issue reported by Guido Vranken.

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

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.

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