apps/CA.pl.in | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

---

config | 4 2 + 2 - 0 !
1 file changed, 2 insertions(+), 2 deletions(-)

---

Configure | 53 53 + 0 - 0 !
1 file changed, 53 insertions(+)

---

Configure | 2 1 + 1 - 0 !
Makefile.org | 2 1 + 1 - 0 !
engines/Makefile | 10 5 + 5 - 0 !
engines/ccgost/Makefile | 6 3 + 3 - 0 !
4 files changed, 10 insertions(+), 10 deletions(-)

---

Makefile.org | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---

Makefile.org | 7 4 + 3 - 0 !
1 file changed, 4 insertions(+), 3 deletions(-)

---

Makefile.shared | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---

Makefile.shared | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---

crypto/des/asm/desboth.pl | 17 14 + 3 - 0 !
crypto/perlasm/cbc.pl | 24 20 + 4 - 0 !
crypto/perlasm/x86gas.pl | 16 16 + 0 - 0 !
crypto/x86cpuid.pl | 10 5 + 5 - 0 !
4 files changed, 55 insertions(+), 12 deletions(-)

---

crypto/rand/md_rand.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

---

tools/c_rehash.in | 12 9 + 3 - 0 !
1 file changed, 9 insertions(+), 3 deletions(-)

---

Configure | 3 2 + 1 - 0 !
1 file changed, 2 insertions(+), 1 deletion(-)

---

crypto/sha/sha.h | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---

Configure | 2 2 + 0 - 0 !
engines/ccgost/openssl.ld | 10 10 + 0 - 0 !
engines/openssl.ld | 10 10 + 0 - 0 !
openssl.ld | 4626 4626 + 0 - 0 !
4 files changed, 4648 insertions(+)

---

tools/c_rehash.in | 8 7 + 1 - 0 !
1 file changed, 7 insertions(+), 1 deletion(-)

 [patch] also create old hash for compatibility

crypto/x509/x509_vfy.c | 26 26 + 0 - 0 !
1 file changed, 26 insertions(+)

 make x509_verify_cert indicate that any certificate whose
 name contains "DigiNotar" is revoked.

crypto/x509/x509_vfy.c | 7 4 + 3 - 0 !
1 file changed, 4 insertions(+), 3 deletions(-)

 make x509_verify_cert indicate that any certificate whose
 name contains "Digicert Sdn. Bhd." (from Malaysia) is revoked.

apps/genrsa.c | 2 1 + 1 - 0 !
apps/openssl.cnf | 2 1 + 1 - 0 !
crypto/dsa/dsa_ameth.c | 2 1 + 1 - 0 !
crypto/ec/ec_ameth.c | 2 1 + 1 - 0 !
crypto/hmac/hm_ameth.c | 2 1 + 1 - 0 !
crypto/rsa/rsa_ameth.c | 2 1 + 1 - 0 !
6 files changed, 6 insertions(+), 6 deletions(-)

 change default bit size and digest
Date: Fri, 01 Nov 2013 20:47:14 +0100

crypto/bn/asm/x86_64-gcc.c | 14 7 + 7 - 0 !
1 file changed, 7 insertions(+), 7 deletions(-)

---

crypto/aes/asm/aes-ppc.pl | 113 100 + 13 - 0 !
crypto/perlasm/ppc-xlate.pl | 45 38 + 7 - 0 !
crypto/sha/asm/sha1-ppc.pl | 30 26 + 4 - 0 !
crypto/sha/asm/sha512-ppc.pl | 107 65 + 42 - 0 !
4 files changed, 229 insertions(+), 66 deletions(-)

---

test/smime-certs/smdsa1.pem | 75 44 + 31 - 0 !
test/smime-certs/smdsa2.pem | 75 44 + 31 - 0 !
test/smime-certs/smdsa3.pem | 75 44 + 31 - 0 !
test/smime-certs/smroot.pem | 75 47 + 28 - 0 !
test/smime-certs/smrsa1.pem | 74 46 + 28 - 0 !
test/smime-certs/smrsa2.pem | 74 46 + 28 - 0 !
test/smime-certs/smrsa3.pem | 74 46 + 28 - 0 !
7 files changed, 317 insertions(+), 205 deletions(-)

 [patch] update s/mime certificates.

crypto/asn1/x_name.c | 6 2 + 4 - 0 !
1 file changed, 2 insertions(+), 4 deletions(-)

 [patch] 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

ssl/s3_srvr.c | 14 7 + 7 - 0 !
ssl/ssl_sess.c | 2 1 + 1 - 0 !
ssl/t1_lib.c | 48 26 + 22 - 0 !
3 files changed, 34 insertions(+), 30 deletions(-)

 [patch] 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

crypto/dsa/dsa_ossl.c | 5 4 + 1 - 0 !
1 file changed, 4 insertions(+), 1 deletion(-)

---

ssl/d1_both.c | 32 16 + 16 - 0 !
ssl/d1_clnt.c | 1 1 + 0 - 0 !
ssl/d1_lib.c | 37 26 + 11 - 0 !
ssl/d1_srvr.c | 3 2 + 1 - 0 !
ssl/ssl_locl.h | 3 2 + 1 - 0 !
5 files changed, 47 insertions(+), 29 deletions(-)

 [patch] 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

crypto/ts/ts_lib.c | 5 2 + 3 - 0 !
1 file changed, 2 insertions(+), 3 deletions(-)

 [patch] 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.

ssl/d1_pkt.c | 83 69 + 14 - 0 !
ssl/ssl.h | 1 1 + 0 - 0 !
ssl/ssl_err.c | 4 3 + 1 - 0 !
3 files changed, 73 insertions(+), 15 deletions(-)

---

crypto/bn/bn_print.c | 12 8 + 4 - 0 !
1 file changed, 8 insertions(+), 4 deletions(-)

---

ssl/s3_lib.c | 34 17 + 17 - 0 !
1 file changed, 17 insertions(+), 17 deletions(-)

 [patch] sweet32 (cve-2016-2183): move des from high to medium
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

ssl/t1_lib.c | 11 8 + 3 - 0 !
1 file changed, 8 insertions(+), 3 deletions(-)

 [patch] 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

crypto/mdc2/mdc2dgst.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch] avoid overflow in mdc2_update()

Thanks to Shi Lei for reporting this issue.

CVE-2016-6303

ssl/t1_lib.c | 24 17 + 7 - 0 !
1 file changed, 17 insertions(+), 7 deletions(-)

 [patch] fix ocsp status request extension unbounded memory growth

A malicious client can send an excessively large OCSP Status Request
extension. If that client continually requests renegotiation,
sending a large OCSP Status Request extension each time, then there will
be unbounded memory growth on the server. This will eventually lead to a
Denial Of Service attack through memory exhaustion. Servers with a
default configuration are vulnerable even if they do not support OCSP.
Builds using the "no-ocsp" build time option are not affected.

I have also checked other extensions to see if they suffer from a similar
problem but I could not find any other issues.

CVE-2016-6304

Issue reported by Shi Lei.

ssl/d1_both.c | 5 4 + 1 - 0 !
ssl/s3_both.c | 6 5 + 1 - 0 !
ssl/s3_clnt.c | 11 11 + 0 - 0 !
ssl/s3_srvr.c | 6 6 + 0 - 0 !
4 files changed, 26 insertions(+), 2 deletions(-)

 [patch] fix small oob reads.

In ssl3_get_client_certificate, ssl3_get_server_certificate and
ssl3_get_certificate_request check we have enough room
before reading a length.

Thanks to Shi Lei (Gear Team, Qihoo 360 Inc.) for reporting these bugs.

CVE-2016-6306

ssl/d1_pkt.c | 15 15 + 0 - 0 !
ssl/s3_pkt.c | 28 20 + 8 - 0 !
ssl/ssl.h | 1 1 + 0 - 0 !
ssl/ssl_locl.h | 4 4 + 0 - 0 !
4 files changed, 40 insertions(+), 8 deletions(-)

 cve-2016-8610

This is a combination of commit 22646a075e75991b4e8f5d67171e45a6aead5b48 and
f1185392189641014dca94f3fe7834bccb5f4c16

index 7e3a7b480e..cb74d467bb 100644

crypto/evp/e_rc4_hmac_md5.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

 [patch] crypto/evp: harden rc4_md5 cipher.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Originally a crash in 32-bit build was reported CHACHA20-POLY1305
cipher. The crash is triggered by truncated packet and is result
of excessive hashing to the edge of accessible memory (or bogus
MAC value is produced if x86 MD5 assembly module is involved). Since
hash operation is read-only it is not considered to be exploitable
beyond a DoS condition.

Thanks to Robert wicki for report.

CVE-2017-3731

crypto/ecdsa/ecs_ossl.c | 2 2 + 0 - 0 !
1 file changed, 2 insertions(+)

---

crypto/x509v3/v3_addr.c | 10 6 + 4 - 0 !
1 file changed, 6 insertions(+), 4 deletions(-)

 [patch] avoid out-of-bounds read

Fixes CVE 2017-3735

crypto/asn1/asn1.h | 1 1 + 0 - 0 !
crypto/asn1/asn1_err.c | 3 2 + 1 - 0 !
crypto/asn1/tasn_dec.c | 62 41 + 21 - 0 !
3 files changed, 44 insertions(+), 22 deletions(-)

 [patch] limit asn.1 constructed types recursive definition depth

Constructed types with a recursive definition (such as can be found in
PKCS7) could eventually exceed the stack given malicious input with
excessive recursion. Therefore we limit the stack depth.

CVE-2018-0739

Credit to OSSFuzz for finding this issue.