aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorNatanael Copa <ncopa@alpinelinux.org>2016-09-19 12:32:23 +0000
committerNatanael Copa <ncopa@alpinelinux.org>2016-09-19 12:32:23 +0000
commita879e6eaf315a19b45fd424f12f9bf072b168946 (patch)
treea3c07114bd38c4632d34e12876578169c237b350
parentd1df1621cd8cdf645c22b9cc6256957208c6ff69 (diff)
downloadaports-a879e6eaf315a19b45fd424f12f9bf072b168946.tar.bz2
aports-a879e6eaf315a19b45fd424f12f9bf072b168946.tar.xz
main/openssl: security fixes
-rw-r--r--main/openssl/APKBUILD39
-rw-r--r--main/openssl/CVE-2016-2179.patch253
-rw-r--r--main/openssl/CVE-2016-2180.patch39
-rw-r--r--main/openssl/CVE-2016-2181.patch351
-rw-r--r--main/openssl/CVE-2016-6302.patch52
-rw-r--r--main/openssl/CVE-2016-6303.patch31
6 files changed, 761 insertions, 4 deletions
diff --git a/main/openssl/APKBUILD b/main/openssl/APKBUILD
index 386862f157..7880242ebc 100644
--- a/main/openssl/APKBUILD
+++ b/main/openssl/APKBUILD
@@ -1,7 +1,7 @@
# Maintainer: Timo Teras <timo.teras@iki.fi>
pkgname=openssl
pkgver=1.0.1t
-pkgrel=1
+pkgrel=2
pkgdesc="Toolkit for SSL v2/v3 and TLS v1"
url="http://openssl.org"
depends=
@@ -31,8 +31,24 @@ source="http://www.openssl.org/source/${pkgname}-${pkgver}.tar.gz
1004-crypto-engine-autoload-padlock-dynamic-engine.patch
CVE-2016-2177.patch
CVE-2016-2178.patch
+ CVE-2016-2179.patch
+ CVE-2016-2180.patch
+ CVE-2016-2181.patch
+ CVE-2016-6302.patch
+ CVE-2016-6303.patch
"
+# secfixes:
+# 1.0.1t-r1:
+# - CVE-2016-2177
+# - CVE-2016-2178
+# 1.0.1t-r2:
+# - CVE-2016-2179
+# - CVE-2016-2180
+# - CVE-2016-2181
+# - CVE-2016-6302
+# - CVE-2016-6303
+
_builddir="$srcdir"/$pkgname-$pkgver
prepare() {
@@ -136,7 +152,12 @@ aa16c89b283faf0fe546e3f897279c44 1002-backport-changes-from-upstream-padlock-mo
57cca845e22c178c3b317010be56edf0 1003-engines-e_padlock-implement-sha1-sha224-sha256-accel.patch
2ac874d1249f5f68d8c7cd58d157d29a 1004-crypto-engine-autoload-padlock-dynamic-engine.patch
b0eb90bff760a38cca1fd096c630ce4d CVE-2016-2177.patch
-625769139b7a7321e70266b18467ae1b CVE-2016-2178.patch"
+625769139b7a7321e70266b18467ae1b CVE-2016-2178.patch
+548bddfb24e64868ed8f55d057d1f39e CVE-2016-2179.patch
+2fffebea71addf58cb0bb2774647419b CVE-2016-2180.patch
+3061d63f56082f27fe2e16015f916901 CVE-2016-2181.patch
+ff6f4883d444574f69dd8831ac1cb7c9 CVE-2016-6302.patch
+21168cefdf2c016651205cfe3c0dc32d CVE-2016-6303.patch"
sha256sums="4a6ee491a2fdb22e519c76fdc2a628bb3cec12762cd456861d207996c8a07088 openssl-1.0.1t.tar.gz
df795e988fb9d55b4ddd775fbb2d5f0a3bd77af8c46f04d4199c0f75a56c0386 0001-fix-manpages.patch
b449fb998b5f60a3a1779ac2f432b2c7f08ae52fc6dfa98bca37d735f863d400 0002-busybox-basename.patch
@@ -153,7 +174,12 @@ aee88a24622ce9d71e38deeb874e58435dcf8ff5690f56194f0e4a00fb09b260 1002-backport-
c10b8aaf56a4f4f79ca195fc587e0bb533f643e777d7a3e6fb0350399a6060ea 1003-engines-e_padlock-implement-sha1-sha224-sha256-accel.patch
2f7c850af078a3ae71b2dd38d5d0b3964ea4262e52673e36ff33498cc6223e6c 1004-crypto-engine-autoload-padlock-dynamic-engine.patch
285019f7c51bc968e6655f5ef573d6a9a7165ab45e89977ea097b882a14c83e3 CVE-2016-2177.patch
-4e1883eb0d4e38d56ed9fcc2e566323da500c384fcdfe4be186b3bda5b99ccca CVE-2016-2178.patch"
+4e1883eb0d4e38d56ed9fcc2e566323da500c384fcdfe4be186b3bda5b99ccca CVE-2016-2178.patch
+f108f22e7954fa6b6d074bc8f32678b9e04f36744a1fd5f337c7c64d6fbef0eb CVE-2016-2179.patch
+06a9add56874bd1647704352906420acc62e889eca27e576588f2c6440043fe5 CVE-2016-2180.patch
+17b8055b08cb93332aa01c35e04c1fb9a557d0ca7003145185da720129c1b4a7 CVE-2016-2181.patch
+4ff50c874f457b460630c3529e467d3f74ecd9bf4d8a1fba6a405c5f2f5fd55e CVE-2016-6302.patch
+363a2ee3e3763084ae7d117c83fbd874cb10ce19156b8ca7f5c89a55f3a94d97 CVE-2016-6303.patch"
sha512sums="31f0689e71ce2ec3ebbe01c481368d58d4fb2cb2444efcb47c869d3f1a2accc573f1e0cbc8f45faf437437639bf3a86a5f2e3dd1698ec08c009ab5b560e74b73 openssl-1.0.1t.tar.gz
5f31d53b5658d96a760020fff2f350a3fe50b96b33fb52ace935e3f3c1c011b93a6abd1e9bc1376c5f91dd32daa25b58483491cc43639b31e3e5cb7a73477767 0001-fix-manpages.patch
2244f46cb18e6b98f075051dd2446c47f7590abccd108fbab707f168a20cad8d32220d704635973f09e3b2879f523be5160f1ffbc12ab3900f8a8891dc855c5c 0002-busybox-basename.patch
@@ -170,4 +196,9 @@ a3555440b5f544bfd6b9ad97557d8f4c1d673f6a35219f65056a72035d186be5f354717ddf978489
6353c7a94016c20db5d683dde37775f6780952ecdb1a5f39f878d04ba37f6ad79ae10fb6d65d181d912505a5d1e22463004cd855d548b364c00b120da2b0fdbc 1003-engines-e_padlock-implement-sha1-sha224-sha256-accel.patch
b72436eb8d4dac42d8da76a51d46cfc03e92e162f692a7a1761201221b9c6d66b738c08270b2260f02ce47b42043538474df73a7185dd4a809dd3b14cc8af7c3 1004-crypto-engine-autoload-padlock-dynamic-engine.patch
39650e019bf283b4fdb9c679643d3b84a21f90e0682a2abd8800a03c57ce1ffe02d7a98d427f746aa07fdda52ec149d73df50d430c5ef081dad9d7f69e7ceb3b CVE-2016-2177.patch
-4e9d66380d81f015c64f027c73029ad3042f19ae3f30b558b8a2313fb56a1374dc8924341968cd29def84b573fce7a8d3890c51fa25311b24c4e7ddd6c152905 CVE-2016-2178.patch"
+4e9d66380d81f015c64f027c73029ad3042f19ae3f30b558b8a2313fb56a1374dc8924341968cd29def84b573fce7a8d3890c51fa25311b24c4e7ddd6c152905 CVE-2016-2178.patch
+b78911bbc8e56a7fda29dabdc1cfabfb53e57e5b0f0415869716fd60cadbf96ee1a6e901fc6ffd57566346c83e212703f6df75befad350939637496dbe2ca817 CVE-2016-2179.patch
+c595caf4a775ba10c47f17a8898665c5a5eee73d4449a2b360592a728febfeca8537989272e1e4a144cd438e1b0a329814dec01f785d345d56b197b245e2da5e CVE-2016-2180.patch
+b8a953814dec821ad1111ae8e6188752867dcebb56783acb58f776fc48e037335e1074e26e2fe1b144d32abe10a57a6ecf83fce8bf39345a443ad973aa056299 CVE-2016-2181.patch
+3b542a2a1efd58cb722069568e1b4cbd060b458a09ecd047c8c11cd26e2264ec12cfbc1c9769d201460770b49680aa06c29968aba756d667f9fada549014f7bd CVE-2016-6302.patch
+33e92f3ee9699601ef81edcd08928101e51672c65b3dc149c0ff57d24ec301209f552f96761c59c88715c996dccce341377883b98c3014f3b31f08d44c33bf78 CVE-2016-6303.patch"
diff --git a/main/openssl/CVE-2016-2179.patch b/main/openssl/CVE-2016-2179.patch
new file mode 100644
index 0000000000..f0bab19c8c
--- /dev/null
+++ b/main/openssl/CVE-2016-2179.patch
@@ -0,0 +1,253 @@
+From 00a4c1421407b6ac796688871b0a49a179c694d9 Mon Sep 17 00:00:00 2001
+From: Matt Caswell <matt@openssl.org>
+Date: Thu, 30 Jun 2016 13:17:08 +0100
+Subject: [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
+
+Reviewed-by: Richard Levitte <levitte@openssl.org>
+---
+ ssl/d1_both.c | 32 ++++++++++++++++----------------
+ ssl/d1_clnt.c | 1 +
+ ssl/d1_lib.c | 37 ++++++++++++++++++++++++++-----------
+ ssl/d1_srvr.c | 3 ++-
+ ssl/ssl_locl.h | 3 ++-
+ 5 files changed, 47 insertions(+), 29 deletions(-)
+
+diff --git a/ssl/d1_both.c b/ssl/d1_both.c
+index 1614d88..ae292c4 100644
+--- a/ssl/d1_both.c
++++ b/ssl/d1_both.c
+@@ -614,11 +614,23 @@ static int dtls1_retrieve_buffered_fragment(SSL *s, long max, int *ok)
+ int al;
+
+ *ok = 0;
+- item = pqueue_peek(s->d1->buffered_messages);
+- if (item == NULL)
+- return 0;
++ do {
++ item = pqueue_peek(s->d1->buffered_messages);
++ if (item == NULL)
++ return 0;
++
++ frag = (hm_fragment *)item->data;
++
++ if (frag->msg_header.seq < s->d1->handshake_read_seq) {
++ /* This is a stale message that has been buffered so clear it */
++ pqueue_pop(s->d1->buffered_messages);
++ dtls1_hm_fragment_free(frag);
++ pitem_free(item);
++ item = NULL;
++ frag = NULL;
++ }
++ } while (item == NULL);
+
+- frag = (hm_fragment *)item->data;
+
+ /* Don't return if reassembly still in progress */
+ if (frag->reassembly != NULL)
+@@ -1416,18 +1428,6 @@ dtls1_retransmit_message(SSL *s, unsigned short seq, unsigned long frag_off,
+ return ret;
+ }
+
+-/* call this function when the buffered messages are no longer needed */
+-void dtls1_clear_record_buffer(SSL *s)
+-{
+- pitem *item;
+-
+- for (item = pqueue_pop(s->d1->sent_messages);
+- item != NULL; item = pqueue_pop(s->d1->sent_messages)) {
+- dtls1_hm_fragment_free((hm_fragment *)item->data);
+- pitem_free(item);
+- }
+-}
+-
+ unsigned char *dtls1_set_message_header(SSL *s, unsigned char *p,
+ unsigned char mt, unsigned long len,
+ unsigned long frag_off,
+diff --git a/ssl/d1_clnt.c b/ssl/d1_clnt.c
+index eb371a2..e1f167b 100644
+--- a/ssl/d1_clnt.c
++++ b/ssl/d1_clnt.c
+@@ -751,6 +751,7 @@ int dtls1_connect(SSL *s)
+ /* done with handshaking */
+ s->d1->handshake_read_seq = 0;
+ s->d1->next_handshake_write_seq = 0;
++ dtls1_clear_received_buffer(s);
+ goto end;
+ /* break; */
+
+diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
+index 011d7b7..99984df 100644
+--- a/ssl/d1_lib.c
++++ b/ssl/d1_lib.c
+@@ -144,7 +144,6 @@ int dtls1_new(SSL *s)
+ static void dtls1_clear_queues(SSL *s)
+ {
+ pitem *item = NULL;
+- hm_fragment *frag = NULL;
+ DTLS1_RECORD_DATA *rdata;
+
+ while ((item = pqueue_pop(s->d1->unprocessed_rcds.q)) != NULL) {
+@@ -165,28 +164,44 @@ static void dtls1_clear_queues(SSL *s)
+ pitem_free(item);
+ }
+
++ while ((item = pqueue_pop(s->d1->buffered_app_data.q)) != NULL) {
++ rdata = (DTLS1_RECORD_DATA *)item->data;
++ if (rdata->rbuf.buf) {
++ OPENSSL_free(rdata->rbuf.buf);
++ }
++ OPENSSL_free(item->data);
++ pitem_free(item);
++ }
++
++ dtls1_clear_received_buffer(s);
++ dtls1_clear_sent_buffer(s);
++}
++
++void dtls1_clear_received_buffer(SSL *s)
++{
++ pitem *item = NULL;
++ hm_fragment *frag = NULL;
++
+ while ((item = pqueue_pop(s->d1->buffered_messages)) != NULL) {
+ frag = (hm_fragment *)item->data;
+ dtls1_hm_fragment_free(frag);
+ pitem_free(item);
+ }
++}
++
++void dtls1_clear_sent_buffer(SSL *s)
++{
++ pitem *item = NULL;
++ hm_fragment *frag = NULL;
+
+ while ((item = pqueue_pop(s->d1->sent_messages)) != NULL) {
+ frag = (hm_fragment *)item->data;
+ dtls1_hm_fragment_free(frag);
+ pitem_free(item);
+ }
+-
+- while ((item = pqueue_pop(s->d1->buffered_app_data.q)) != NULL) {
+- rdata = (DTLS1_RECORD_DATA *)item->data;
+- if (rdata->rbuf.buf) {
+- OPENSSL_free(rdata->rbuf.buf);
+- }
+- OPENSSL_free(item->data);
+- pitem_free(item);
+- }
+ }
+
++
+ void dtls1_free(SSL *s)
+ {
+ ssl3_free(s);
+@@ -420,7 +435,7 @@ void dtls1_stop_timer(SSL *s)
+ BIO_ctrl(SSL_get_rbio(s), BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT, 0,
+ &(s->d1->next_timeout));
+ /* Clear retransmission buffer */
+- dtls1_clear_record_buffer(s);
++ dtls1_clear_sent_buffer(s);
+ }
+
+ int dtls1_check_timeout_num(SSL *s)
+diff --git a/ssl/d1_srvr.c b/ssl/d1_srvr.c
+index 60af230..bc30433 100644
+--- a/ssl/d1_srvr.c
++++ b/ssl/d1_srvr.c
+@@ -295,7 +295,7 @@ int dtls1_accept(SSL *s)
+ case SSL3_ST_SW_HELLO_REQ_B:
+
+ s->shutdown = 0;
+- dtls1_clear_record_buffer(s);
++ dtls1_clear_sent_buffer(s);
+ dtls1_start_timer(s);
+ ret = dtls1_send_hello_request(s);
+ if (ret <= 0)
+@@ -866,6 +866,7 @@ int dtls1_accept(SSL *s)
+ /* next message is server hello */
+ s->d1->handshake_write_seq = 0;
+ s->d1->next_handshake_write_seq = 0;
++ dtls1_clear_received_buffer(s);
+ goto end;
+ /* break; */
+
+diff --git a/ssl/ssl_locl.h b/ssl/ssl_locl.h
+index d57b902..7b1fd1f 100644
+--- a/ssl/ssl_locl.h
++++ b/ssl/ssl_locl.h
+@@ -1026,7 +1026,8 @@ int dtls1_retransmit_message(SSL *s, unsigned short seq,
+ unsigned long frag_off, int *found);
+ int dtls1_get_queue_priority(unsigned short seq, int is_ccs);
+ int dtls1_retransmit_buffered_messages(SSL *s);
+-void dtls1_clear_record_buffer(SSL *s);
++void dtls1_clear_received_buffer(SSL *s);
++void dtls1_clear_sent_buffer(SSL *s);
+ void dtls1_get_message_header(unsigned char *data,
+ struct hm_header_st *msg_hdr);
+ void dtls1_get_ccs_header(unsigned char *data, struct ccs_header_st *ccs_hdr);
+--
+1.9.1
+
diff --git a/main/openssl/CVE-2016-2180.patch b/main/openssl/CVE-2016-2180.patch
new file mode 100644
index 0000000000..a4d3a7cb84
--- /dev/null
+++ b/main/openssl/CVE-2016-2180.patch
@@ -0,0 +1,39 @@
+From 6adf409c7432b90c06d9890787fe56c48f2a16e7 Mon Sep 17 00:00:00 2001
+From: "Dr. Stephen Henson" <steve@openssl.org>
+Date: Thu, 21 Jul 2016 15:24:16 +0100
+Subject: [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.
+
+Reviewed-by: Matt Caswell <matt@openssl.org>
+(cherry picked from commit 0ed26acce328ec16a3aa635f1ca37365e8c7403a)
+---
+ crypto/ts/ts_lib.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/crypto/ts/ts_lib.c b/crypto/ts/ts_lib.c
+index c51538a..e0f1063 100644
+--- a/crypto/ts/ts_lib.c
++++ b/crypto/ts/ts_lib.c
+@@ -90,9 +90,8 @@ int TS_OBJ_print_bio(BIO *bio, const ASN1_OBJECT *obj)
+ {
+ char obj_txt[128];
+
+- int len = OBJ_obj2txt(obj_txt, sizeof(obj_txt), obj, 0);
+- BIO_write(bio, obj_txt, len);
+- BIO_write(bio, "\n", 1);
++ OBJ_obj2txt(obj_txt, sizeof(obj_txt), obj, 0);
++ BIO_printf(bio, "%s\n", obj_txt);
+
+ return 1;
+ }
+--
+1.9.1
+
diff --git a/main/openssl/CVE-2016-2181.patch b/main/openssl/CVE-2016-2181.patch
new file mode 100644
index 0000000000..51a02e9c84
--- /dev/null
+++ b/main/openssl/CVE-2016-2181.patch
@@ -0,0 +1,351 @@
+From fa75569758298e2930c78989b516cac937118acc Mon Sep 17 00:00:00 2001
+From: Matt Caswell <matt@openssl.org>
+Date: Tue, 5 Jul 2016 11:46:26 +0100
+Subject: [PATCH] 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>
+---
+ ssl/d1_pkt.c | 23 +++++++++++++++++++++--
+ 1 file changed, 21 insertions(+), 2 deletions(-)
+
+diff --git a/ssl/d1_pkt.c b/ssl/d1_pkt.c
+index ea93a8e..78a2a7d 100644
+--- a/ssl/d1_pkt.c
++++ b/ssl/d1_pkt.c
+@@ -319,6 +319,7 @@ static int dtls1_retrieve_buffered_record(SSL *s, record_pqueue *queue)
+ static int dtls1_process_buffered_records(SSL *s)
+ {
+ pitem *item;
++ SSL3_BUFFER *rb;
+
+ item = pqueue_peek(s->d1->unprocessed_rcds.q);
+ if (item) {
+@@ -326,6 +327,19 @@ static int dtls1_process_buffered_records(SSL *s)
+ if (s->d1->unprocessed_rcds.epoch != s->d1->r_epoch)
+ return (1); /* Nothing to do. */
+
++ rb = &s->s3->rbuf;
++
++ if (rb->left > 0) {
++ /*
++ * We've still got data from the current packet to read. There could
++ * be a record from the new epoch in it - so don't overwrite it
++ * with the unprocessed records yet (we'll do it when we've
++ * finished reading the current packet).
++ */
++ return 1;
++ }
++
++
+ /* Process all the records. */
+ while (pqueue_peek(s->d1->unprocessed_rcds.q)) {
+ dtls1_get_unprocessed_record(s);
+@@ -581,6 +595,7 @@ int dtls1_get_record(SSL *s)
+
+ rr = &(s->s3->rrec);
+
++ again:
+ /*
+ * The epoch may have changed. If so, process all the pending records.
+ * This is a non-blocking operation.
+@@ -593,7 +608,6 @@ int dtls1_get_record(SSL *s)
+ return 1;
+
+ /* get something from the wire */
+- again:
+ /* check if we have the header */
+ if ((s->rstate != SSL_ST_READ_BODY) ||
+ (s->packet_length < DTLS1_RT_HEADER_LENGTH)) {
+@@ -1815,8 +1829,13 @@ static DTLS1_BITMAP *dtls1_get_bitmap(SSL *s, SSL3_RECORD *rr,
+ if (rr->epoch == s->d1->r_epoch)
+ return &s->d1->bitmap;
+
+- /* Only HM and ALERT messages can be from the next epoch */
++ /*
++ * Only HM and ALERT messages can be from the next epoch and only if we
++ * have already processed all of the unprocessed records from the last
++ * epoch
++ */
+ else if (rr->epoch == (unsigned long)(s->d1->r_epoch + 1) &&
++ s->d1->unprocessed_rcds.epoch != s->d1->r_epoch &&
+ (rr->type == SSL3_RT_HANDSHAKE || rr->type == SSL3_RT_ALERT)) {
+ *is_next_epoch = 1;
+ return &s->d1->next_bitmap;
+--
+1.9.1
+
+From b77ab018b79a00f789b0fb85596b446b08be4c9d Mon Sep 17 00:00:00 2001
+From: Matt Caswell <matt@openssl.org>
+Date: Tue, 5 Jul 2016 12:04:37 +0100
+Subject: [PATCH] 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>
+---
+ ssl/d1_pkt.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++------------
+ ssl/ssl.h | 1 +
+ ssl/ssl_err.c | 4 +++-
+ 3 files changed, 52 insertions(+), 13 deletions(-)
+
+diff --git a/ssl/d1_pkt.c b/ssl/d1_pkt.c
+index 78a2a7d..d3ceae0 100644
+--- a/ssl/d1_pkt.c
++++ b/ssl/d1_pkt.c
+@@ -194,7 +194,7 @@ static int dtls1_record_needs_buffering(SSL *s, SSL3_RECORD *rr,
+ #endif
+ static int dtls1_buffer_record(SSL *s, record_pqueue *q,
+ unsigned char *priority);
+-static int dtls1_process_record(SSL *s);
++static int dtls1_process_record(SSL *s, DTLS1_BITMAP *bitmap);
+
+ /* copy buffered record into SSL structure */
+ static int dtls1_copy_record(SSL *s, pitem *item)
+@@ -320,13 +320,18 @@ static int dtls1_process_buffered_records(SSL *s)
+ {
+ pitem *item;
+ SSL3_BUFFER *rb;
++ SSL3_RECORD *rr;
++ DTLS1_BITMAP *bitmap;
++ unsigned int is_next_epoch;
++ int replayok = 1;
+
+ item = pqueue_peek(s->d1->unprocessed_rcds.q);
+ if (item) {
+ /* Check if epoch is current. */
+ if (s->d1->unprocessed_rcds.epoch != s->d1->r_epoch)
+- return (1); /* Nothing to do. */
++ return 1; /* Nothing to do. */
+
++ rr = &s->s3->rrec;
+ rb = &s->s3->rbuf;
+
+ if (rb->left > 0) {
+@@ -343,11 +348,41 @@ static int dtls1_process_buffered_records(SSL *s)
+ /* Process all the records. */
+ while (pqueue_peek(s->d1->unprocessed_rcds.q)) {
+ dtls1_get_unprocessed_record(s);
+- if (!dtls1_process_record(s))
+- return (0);
++ bitmap = dtls1_get_bitmap(s, rr, &is_next_epoch);
++ if (bitmap == NULL) {
++ /*
++ * Should not happen. This will only ever be NULL when the
++ * current record is from a different epoch. But that cannot
++ * be the case because we already checked the epoch above
++ */
++ SSLerr(SSL_F_DTLS1_PROCESS_BUFFERED_RECORDS,
++ ERR_R_INTERNAL_ERROR);
++ return 0;
++ }
++#ifndef OPENSSL_NO_SCTP
++ /* Only do replay check if no SCTP bio */
++ if (!BIO_dgram_is_sctp(SSL_get_rbio(s)))
++#endif
++ {
++ /*
++ * Check whether this is a repeat, or aged record. We did this
++ * check once already when we first received the record - but
++ * we might have updated the window since then due to
++ * records we subsequently processed.
++ */
++ replayok = dtls1_record_replay_check(s, bitmap);
++ }
++
++ if (!replayok || !dtls1_process_record(s, bitmap)) {
++ /* dump this record */
++ rr->length = 0;
++ s->packet_length = 0;
++ continue;
++ }
++
+ if (dtls1_buffer_record(s, &(s->d1->processed_rcds),
+ s->s3->rrec.seq_num) < 0)
+- return -1;
++ return 0;
+ }
+ }
+
+@@ -358,7 +393,7 @@ static int dtls1_process_buffered_records(SSL *s)
+ s->d1->processed_rcds.epoch = s->d1->r_epoch;
+ s->d1->unprocessed_rcds.epoch = s->d1->r_epoch + 1;
+
+- return (1);
++ return 1;
+ }
+
+ #if 0
+@@ -405,7 +440,7 @@ static int dtls1_get_buffered_record(SSL *s)
+
+ #endif
+
+-static int dtls1_process_record(SSL *s)
++static int dtls1_process_record(SSL *s, DTLS1_BITMAP *bitmap)
+ {
+ int i, al;
+ int enc_err;
+@@ -565,6 +600,10 @@ static int dtls1_process_record(SSL *s)
+
+ /* we have pulled in a full packet so zero things */
+ s->packet_length = 0;
++
++ /* Mark receipt of record. */
++ dtls1_record_bitmap_update(s, bitmap);
++
+ return (1);
+
+ f_err:
+@@ -600,7 +639,7 @@ int dtls1_get_record(SSL *s)
+ * The epoch may have changed. If so, process all the pending records.
+ * This is a non-blocking operation.
+ */
+- if (dtls1_process_buffered_records(s) < 0)
++ if (!dtls1_process_buffered_records(s))
+ return -1;
+
+ /* if we're renegotiating, then there may be buffered records */
+@@ -731,20 +770,17 @@ int dtls1_get_record(SSL *s)
+ if (dtls1_buffer_record
+ (s, &(s->d1->unprocessed_rcds), rr->seq_num) < 0)
+ return -1;
+- /* Mark receipt of record. */
+- dtls1_record_bitmap_update(s, bitmap);
+ }
+ rr->length = 0;
+ s->packet_length = 0;
+ goto again;
+ }
+
+- if (!dtls1_process_record(s)) {
++ if (!dtls1_process_record(s, bitmap)) {
+ rr->length = 0;
+ s->packet_length = 0; /* dump this record */
+ goto again; /* get another record */
+ }
+- dtls1_record_bitmap_update(s, bitmap); /* Mark receipt of record. */
+
+ return (1);
+
+diff --git a/ssl/ssl.h b/ssl/ssl.h
+index d6c475c..8094450 100644
+--- a/ssl/ssl.h
++++ b/ssl/ssl.h
+@@ -2256,6 +2256,7 @@ void ERR_load_SSL_strings(void);
+ # define SSL_F_DTLS1_HEARTBEAT 305
+ # define SSL_F_DTLS1_OUTPUT_CERT_CHAIN 255
+ # define SSL_F_DTLS1_PREPROCESS_FRAGMENT 288
++# define SSL_F_DTLS1_PROCESS_BUFFERED_RECORDS 404
+ # define SSL_F_DTLS1_PROCESS_OUT_OF_SEQ_MESSAGE 256
+ # define SSL_F_DTLS1_PROCESS_RECORD 257
+ # define SSL_F_DTLS1_READ_BYTES 258
+diff --git a/ssl/ssl_err.c b/ssl/ssl_err.c
+index caa671a..ed679d1 100644
+--- a/ssl/ssl_err.c
++++ b/ssl/ssl_err.c
+@@ -1,6 +1,6 @@
+ /* ssl/ssl_err.c */
+ /* ====================================================================
+- * Copyright (c) 1999-2011 The OpenSSL Project. All rights reserved.
++ * Copyright (c) 1999-2016 The OpenSSL Project. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+@@ -93,6 +93,8 @@ static ERR_STRING_DATA SSL_str_functs[] = {
+ {ERR_FUNC(SSL_F_DTLS1_HEARTBEAT), "DTLS1_HEARTBEAT"},
+ {ERR_FUNC(SSL_F_DTLS1_OUTPUT_CERT_CHAIN), "DTLS1_OUTPUT_CERT_CHAIN"},
+ {ERR_FUNC(SSL_F_DTLS1_PREPROCESS_FRAGMENT), "DTLS1_PREPROCESS_FRAGMENT"},
++ {ERR_FUNC(SSL_F_DTLS1_PROCESS_BUFFERED_RECORDS),
++ "DTLS1_PROCESS_BUFFERED_RECORDS"},
+ {ERR_FUNC(SSL_F_DTLS1_PROCESS_OUT_OF_SEQ_MESSAGE),
+ "DTLS1_PROCESS_OUT_OF_SEQ_MESSAGE"},
+ {ERR_FUNC(SSL_F_DTLS1_PROCESS_RECORD), "DTLS1_PROCESS_RECORD"},
+--
+1.9.1
+
+From 5802758eb480c5f14a768f6a061df1dd20aec8c4 Mon Sep 17 00:00:00 2001
+From: Matt Caswell <matt@openssl.org>
+Date: Wed, 17 Aug 2016 17:55:36 +0100
+Subject: [PATCH] Update function error code
+
+A function error code needed updating due to merge issues.
+
+Reviewed-by: Richard Levitte <levitte@openssl.org>
+---
+ ssl/ssl.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/ssl/ssl.h b/ssl/ssl.h
+index 8094450..114ee97 100644
+--- a/ssl/ssl.h
++++ b/ssl/ssl.h
+@@ -2256,7 +2256,7 @@ void ERR_load_SSL_strings(void);
+ # define SSL_F_DTLS1_HEARTBEAT 305
+ # define SSL_F_DTLS1_OUTPUT_CERT_CHAIN 255
+ # define SSL_F_DTLS1_PREPROCESS_FRAGMENT 288
+-# define SSL_F_DTLS1_PROCESS_BUFFERED_RECORDS 404
++# define SSL_F_DTLS1_PROCESS_BUFFERED_RECORDS 424
+ # define SSL_F_DTLS1_PROCESS_OUT_OF_SEQ_MESSAGE 256
+ # define SSL_F_DTLS1_PROCESS_RECORD 257
+ # define SSL_F_DTLS1_READ_BYTES 258
+--
+1.9.1
+
diff --git a/main/openssl/CVE-2016-6302.patch b/main/openssl/CVE-2016-6302.patch
new file mode 100644
index 0000000000..52233b9023
--- /dev/null
+++ b/main/openssl/CVE-2016-6302.patch
@@ -0,0 +1,52 @@
+From 1bbe48ab149893a78bf99c8eb8895c928900a16f Mon Sep 17 00:00:00 2001
+From: "Dr. Stephen Henson" <steve@openssl.org>
+Date: Tue, 23 Aug 2016 18:14:54 +0100
+Subject: [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
+
+Reviewed-by: Rich Salz <rsalz@openssl.org>
+(cherry picked from commit baaabfd8fdcec04a691695fad9a664bea43202b6)
+---
+ ssl/t1_lib.c | 11 ++++++++---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
+index d961e4a..7680491 100644
+--- a/ssl/t1_lib.c
++++ b/ssl/t1_lib.c
+@@ -2273,9 +2273,7 @@ static int tls_decrypt_ticket(SSL *s, const unsigned char *etick,
+ HMAC_CTX hctx;
+ EVP_CIPHER_CTX ctx;
+ SSL_CTX *tctx = s->initial_ctx;
+- /* Need at least keyname + iv + some encrypted data */
+- if (eticklen < 48)
+- return 2;
++
+ /* Initialize session ticket encryption and HMAC contexts */
+ HMAC_CTX_init(&hctx);
+ EVP_CIPHER_CTX_init(&ctx);
+@@ -2309,6 +2307,13 @@ static int tls_decrypt_ticket(SSL *s, const unsigned char *etick,
+ if (mlen < 0) {
+ goto err;
+ }
++ /* Sanity check ticket length: must exceed keyname + IV + HMAC */
++ if (eticklen <= 16 + EVP_CIPHER_CTX_iv_length(&ctx) + mlen) {
++ HMAC_CTX_cleanup(&hctx);
++ EVP_CIPHER_CTX_cleanup(&ctx);
++ return 2;
++ }
++
+ eticklen -= mlen;
+ /* Check HMAC of encrypted ticket */
+ if (HMAC_Update(&hctx, etick, eticklen) <= 0
+--
+1.9.1
+
diff --git a/main/openssl/CVE-2016-6303.patch b/main/openssl/CVE-2016-6303.patch
new file mode 100644
index 0000000000..45b69c8bcb
--- /dev/null
+++ b/main/openssl/CVE-2016-6303.patch
@@ -0,0 +1,31 @@
+From 2b4029e68fd7002d2307e6c3cde0f3784eef9c83 Mon Sep 17 00:00:00 2001
+From: "Dr. Stephen Henson" <steve@openssl.org>
+Date: Fri, 19 Aug 2016 23:28:29 +0100
+Subject: [PATCH] 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)
+---
+ crypto/mdc2/mdc2dgst.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/crypto/mdc2/mdc2dgst.c b/crypto/mdc2/mdc2dgst.c
+index 6615cf8..2dce493 100644
+--- a/crypto/mdc2/mdc2dgst.c
++++ b/crypto/mdc2/mdc2dgst.c
+@@ -91,7 +91,7 @@ int MDC2_Update(MDC2_CTX *c, const unsigned char *in, size_t len)
+
+ i = c->num;
+ if (i != 0) {
+- if (i + len < MDC2_BLOCK) {
++ if (len < MDC2_BLOCK - i) {
+ /* partial block */
+ memcpy(&(c->data[i]), in, len);
+ c->num += (int)len;
+--
+1.9.1
+