From 96cf162f9d9e83121ec43a8baf940d4ebc75b811 Mon Sep 17 00:00:00 2001 From: Adrian Dudau Date: Tue, 27 Sep 2016 16:38:51 +0200 Subject: openssl: Revert 9 CVE fixes merged upstream Revert "openssl: Security fix CVE-2016-6306" This reverts commit f73e0eb5d77764c00d6ae8db10528522fc8516bc. Revert "openssl: Security fix CVE-2016-6304" This reverts commit 35f3007f0e0c56bc2f96ab5893686191d099949f. Revert "openssl: Security fix CVE-2016-6303" This reverts commit 744b01090f6cf4984c11bb682693647a62103644. Revert "openssl: Security fix CVE-2016-6302" This reverts commit 8ac9ad185c0889af0bfb2fcd90a6987cb972eb0a. Revert "openssl: Security fix CVE-2016-2182" This reverts commit c95a5d22dedc5701d18e91e40a0c54802915187d. Revert "openssl: Security fix CVE-2016-2181" This reverts commit f0e2e3d84763477138d902f7d48ac2658266aa2b. Revert "openssl: Security fix CVE-2016-2180" This reverts commit 5493231d1ff5e9b259cd074245e909b5e39d926e. Revert "openssl: Security fix CVE-2016-2179" This reverts commit 331ca6f05824e5b005cbf504233b3c72275181d5. Revert "openssl: Security fix CVE-2016-2178" This reverts commit ac47871dfb962355c3c8971cd2fde2e4d03c9790. Signed-off-by: Adrian Dudau Signed-off-by: Martin Borg --- .../openssl/openssl/CVE-2016-2178.patch | 54 ----- .../openssl/openssl/CVE-2016-2179.patch | 255 --------------------- .../openssl/openssl/CVE-2016-2180.patch | 44 ---- .../openssl/openssl/CVE-2016-2181_p1.patch | 91 -------- .../openssl/openssl/CVE-2016-2181_p2.patch | 239 ------------------- .../openssl/openssl/CVE-2016-2181_p3.patch | 30 --- .../openssl/openssl/CVE-2016-2182.patch | 70 ------ .../openssl/openssl/CVE-2016-6302.patch | 53 ----- .../openssl/openssl/CVE-2016-6303.patch | 36 --- .../openssl/openssl/CVE-2016-6304.patch | 75 ------ .../openssl/openssl/CVE-2016-6306.patch | 71 ------ .../openssl/openssl_1.0.2h.bbappend | 14 -- 12 files changed, 1032 deletions(-) delete mode 100644 recipes-connectivity/openssl/openssl/CVE-2016-2178.patch delete mode 100644 recipes-connectivity/openssl/openssl/CVE-2016-2179.patch delete mode 100644 recipes-connectivity/openssl/openssl/CVE-2016-2180.patch delete mode 100644 recipes-connectivity/openssl/openssl/CVE-2016-2181_p1.patch delete mode 100644 recipes-connectivity/openssl/openssl/CVE-2016-2181_p2.patch delete mode 100644 recipes-connectivity/openssl/openssl/CVE-2016-2181_p3.patch delete mode 100644 recipes-connectivity/openssl/openssl/CVE-2016-2182.patch delete mode 100644 recipes-connectivity/openssl/openssl/CVE-2016-6302.patch delete mode 100644 recipes-connectivity/openssl/openssl/CVE-2016-6303.patch delete mode 100644 recipes-connectivity/openssl/openssl/CVE-2016-6304.patch delete mode 100644 recipes-connectivity/openssl/openssl/CVE-2016-6306.patch delete mode 100644 recipes-connectivity/openssl/openssl_1.0.2h.bbappend diff --git a/recipes-connectivity/openssl/openssl/CVE-2016-2178.patch b/recipes-connectivity/openssl/openssl/CVE-2016-2178.patch deleted file mode 100644 index 07b1310..0000000 --- a/recipes-connectivity/openssl/openssl/CVE-2016-2178.patch +++ /dev/null @@ -1,54 +0,0 @@ -From 621eaf49a289bfac26d4cbcdb7396e796784c534 Mon Sep 17 00:00:00 2001 -From: Cesar Pereida -Date: Mon, 23 May 2016 12:45:25 +0300 -Subject: [PATCH] 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 -Reviewed-by: Matt Caswell - -Upstream-Status: Backport -CVE: CVE-2016-2178 -Signed-off-by: Armin Kuster - ---- - crypto/dsa/dsa_ossl.c | 6 +++--- - 1 file changed, 3 insertions(+), 3 deletions(-) - -diff --git a/crypto/dsa/dsa_ossl.c b/crypto/dsa/dsa_ossl.c -index efc4f1b..b29eb4b 100644 ---- a/crypto/dsa/dsa_ossl.c -+++ b/crypto/dsa/dsa_ossl.c -@@ -248,9 +248,6 @@ static int dsa_sign_setup(DSA *dsa, BN_CTX *ctx_in, BIGNUM **kinvp, - if (!BN_rand_range(&k, dsa->q)) - goto err; - while (BN_is_zero(&k)) ; -- if ((dsa->flags & DSA_FLAG_NO_EXP_CONSTTIME) == 0) { -- BN_set_flags(&k, BN_FLG_CONSTTIME); -- } - - if (dsa->flags & DSA_FLAG_CACHE_MONT_P) { - if (!BN_MONT_CTX_set_locked(&dsa->method_mont_p, -@@ -279,9 +276,12 @@ static int dsa_sign_setup(DSA *dsa, BN_CTX *ctx_in, BIGNUM **kinvp, - } - - K = &kq; -+ -+ BN_set_flags(K, BN_FLG_CONSTTIME); - } else { - K = &k; - } -+ - DSA_BN_MOD_EXP(goto err, dsa, r, dsa->g, K, dsa->p, ctx, - dsa->method_mont_p); - if (!BN_mod(r, r, dsa->q, ctx)) --- -2.7.4 - diff --git a/recipes-connectivity/openssl/openssl/CVE-2016-2179.patch b/recipes-connectivity/openssl/openssl/CVE-2016-2179.patch deleted file mode 100644 index 3a80696..0000000 --- a/recipes-connectivity/openssl/openssl/CVE-2016-2179.patch +++ /dev/null @@ -1,255 +0,0 @@ -From 26f2c5774f117aea588e8f31fad38bcf14e83bec Mon Sep 17 00:00:00 2001 -From: Matt Caswell -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 - -Upstream-Status: Backport -CVE: CVE-2016-2179 -Signed-off-by: Armin Kuster - ---- - 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(-) - -Index: openssl-1.0.2h/ssl/d1_both.c -=================================================================== ---- openssl-1.0.2h.orig/ssl/d1_both.c -+++ openssl-1.0.2h/ssl/d1_both.c -@@ -618,11 +618,23 @@ static int dtls1_retrieve_buffered_fragm - 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) -@@ -1296,18 +1308,6 @@ dtls1_retransmit_message(SSL *s, unsigne - 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, -Index: openssl-1.0.2h/ssl/d1_clnt.c -=================================================================== ---- openssl-1.0.2h.orig/ssl/d1_clnt.c -+++ openssl-1.0.2h/ssl/d1_clnt.c -@@ -769,6 +769,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; */ - -Index: openssl-1.0.2h/ssl/d1_lib.c -=================================================================== ---- openssl-1.0.2h.orig/ssl/d1_lib.c -+++ openssl-1.0.2h/ssl/d1_lib.c -@@ -170,7 +170,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) { -@@ -191,28 +190,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); -@@ -456,7 +471,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) -Index: openssl-1.0.2h/ssl/d1_srvr.c -=================================================================== ---- openssl-1.0.2h.orig/ssl/d1_srvr.c -+++ openssl-1.0.2h/ssl/d1_srvr.c -@@ -313,7 +313,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 = ssl3_send_hello_request(s); - if (ret <= 0) -@@ -894,6 +894,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; */ - -Index: openssl-1.0.2h/ssl/ssl_locl.h -=================================================================== ---- openssl-1.0.2h.orig/ssl/ssl_locl.h -+++ openssl-1.0.2h/ssl/ssl_locl.h -@@ -1242,7 +1242,8 @@ int dtls1_retransmit_message(SSL *s, uns - 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); diff --git a/recipes-connectivity/openssl/openssl/CVE-2016-2180.patch b/recipes-connectivity/openssl/openssl/CVE-2016-2180.patch deleted file mode 100644 index c71aaa5..0000000 --- a/recipes-connectivity/openssl/openssl/CVE-2016-2180.patch +++ /dev/null @@ -1,44 +0,0 @@ -From b746aa3fe05b5b5f7126df247ac3eceeb995e2a0 Mon Sep 17 00:00:00 2001 -From: "Dr. Stephen Henson" -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 -(cherry picked from commit 0ed26acce328ec16a3aa635f1ca37365e8c7403a) - -Upstream-Status: Backport -CVE: CVE-2016-2180 -Signed-off-by: Armin Kuster - ---- - 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; - } --- -2.7.4 - diff --git a/recipes-connectivity/openssl/openssl/CVE-2016-2181_p1.patch b/recipes-connectivity/openssl/openssl/CVE-2016-2181_p1.patch deleted file mode 100644 index 9149dbe..0000000 --- a/recipes-connectivity/openssl/openssl/CVE-2016-2181_p1.patch +++ /dev/null @@ -1,91 +0,0 @@ -From 20744f6b40b5ded059a848f66d6ba922f2a62eb3 Mon Sep 17 00:00:00 2001 -From: Matt Caswell -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 - -Upstream-Status: Backport -CVE: CVE-2016-2180 patch 1 -Signed-off-by: Armin Kuster - ---- - 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 fe30ec7..1fb119d 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)) { -@@ -1830,8 +1844,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; --- -2.7.4 - diff --git a/recipes-connectivity/openssl/openssl/CVE-2016-2181_p2.patch b/recipes-connectivity/openssl/openssl/CVE-2016-2181_p2.patch deleted file mode 100644 index ecf138a..0000000 --- a/recipes-connectivity/openssl/openssl/CVE-2016-2181_p2.patch +++ /dev/null @@ -1,239 +0,0 @@ -From 3884b47b7c255c2e94d9b387ee83c7e8bb981258 Mon Sep 17 00:00:00 2001 -From: Matt Caswell -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 - -Upstream-Status: Backport -CVE: CVE-2016-2181 patch2 -Signed-off-by: Armin Kuster - - -Reviewed-by: Richard Levitte ---- - ssl/d1_pkt.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++------------ - ssl/ssl.h | 1 + - ssl/ssl_err.c | 4 +++- - 3 files changed, 52 insertions(+), 13 deletions(-) - -Index: openssl-1.0.2h/ssl/d1_pkt.c -=================================================================== ---- openssl-1.0.2h.orig/ssl/d1_pkt.c -+++ openssl-1.0.2h/ssl/d1_pkt.c -@@ -194,7 +194,7 @@ static int dtls1_record_needs_buffering( - #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_record - { - 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_record - /* 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_record - 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 - - #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 */ -@@ -735,20 +774,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); - -Index: openssl-1.0.2h/ssl/ssl.h -=================================================================== ---- openssl-1.0.2h.orig/ssl/ssl.h -+++ openssl-1.0.2h/ssl/ssl.h -@@ -2623,6 +2623,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 -Index: openssl-1.0.2h/ssl/ssl_err.c -=================================================================== ---- openssl-1.0.2h.orig/ssl/ssl_err.c -+++ openssl-1.0.2h/ssl/ssl_err.c -@@ -1,6 +1,6 @@ - /* ssl/ssl_err.c */ - /* ==================================================================== -- * Copyright (c) 1999-2015 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"}, diff --git a/recipes-connectivity/openssl/openssl/CVE-2016-2181_p3.patch b/recipes-connectivity/openssl/openssl/CVE-2016-2181_p3.patch deleted file mode 100644 index a752f89..0000000 --- a/recipes-connectivity/openssl/openssl/CVE-2016-2181_p3.patch +++ /dev/null @@ -1,30 +0,0 @@ -From 26aebca74e38ae09f673c2045cc8e2ef762d265a Mon Sep 17 00:00:00 2001 -From: Matt Caswell -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 - -Upstream-Status: Backport -CVE: CVE-2016-2181 patch 3 -Signed-off-by: Armin Kuster - ---- - ssl/ssl.h | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -Index: openssl-1.0.2h/ssl/ssl.h -=================================================================== ---- openssl-1.0.2h.orig/ssl/ssl.h -+++ openssl-1.0.2h/ssl/ssl.h -@@ -2623,7 +2623,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 diff --git a/recipes-connectivity/openssl/openssl/CVE-2016-2182.patch b/recipes-connectivity/openssl/openssl/CVE-2016-2182.patch deleted file mode 100644 index 5995cbe..0000000 --- a/recipes-connectivity/openssl/openssl/CVE-2016-2182.patch +++ /dev/null @@ -1,70 +0,0 @@ -From e36f27ddb80a48e579783bc29fb3758988342b71 Mon Sep 17 00:00:00 2001 -From: "Dr. Stephen Henson" -Date: Fri, 5 Aug 2016 14:26:03 +0100 -Subject: [PATCH] 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 -(cherry picked from commit 07bed46f332fce8c1d157689a2cdf915a982ae34) - -Conflicts: - crypto/bn/bn_print.c - -Upstream-Status: Backport -CVE: CVE-2016-2182 -Signed-off-by: Armin Kuster - ---- - crypto/bn/bn_print.c | 11 ++++++++--- - 1 file changed, 8 insertions(+), 3 deletions(-) - -diff --git a/crypto/bn/bn_print.c b/crypto/bn/bn_print.c -index bfa31ef..b44403e 100644 ---- a/crypto/bn/bn_print.c -+++ b/crypto/bn/bn_print.c -@@ -111,6 +111,7 @@ char *BN_bn2dec(const BIGNUM *a) - char *p; - BIGNUM *t = NULL; - BN_ULONG *bn_data = NULL, *lp; -+ int bn_data_num; - - /*- - * get an upper bound for the length of the decimal integer -@@ -120,9 +121,9 @@ char *BN_bn2dec(const BIGNUM *a) - */ - i = BN_num_bits(a) * 3; - num = (i / 10 + i / 1000 + 1) + 1; -- bn_data = -- (BN_ULONG *)OPENSSL_malloc((num / BN_DEC_NUM + 1) * sizeof(BN_ULONG)); -- buf = (char *)OPENSSL_malloc(num + 3); -+ bn_data_num = num / BN_DEC_NUM + 1; -+ bn_data = OPENSSL_malloc(bn_data_num * sizeof(BN_ULONG)); -+ buf = OPENSSL_malloc(num + 3); - if ((buf == NULL) || (bn_data == NULL)) { - BNerr(BN_F_BN_BN2DEC, ERR_R_MALLOC_FAILURE); - goto err; -@@ -143,7 +144,11 @@ char *BN_bn2dec(const BIGNUM *a) - i = 0; - while (!BN_is_zero(t)) { - *lp = BN_div_word(t, BN_DEC_CONV); -+ if (*lp == (BN_ULONG)-1) -+ goto err; - lp++; -+ if (lp - bn_data >= bn_data_num) -+ goto err; - } - lp--; - /* --- -2.7.4 - diff --git a/recipes-connectivity/openssl/openssl/CVE-2016-6302.patch b/recipes-connectivity/openssl/openssl/CVE-2016-6302.patch deleted file mode 100644 index a72ee70..0000000 --- a/recipes-connectivity/openssl/openssl/CVE-2016-6302.patch +++ /dev/null @@ -1,53 +0,0 @@ -From baaabfd8fdcec04a691695fad9a664bea43202b6 Mon Sep 17 00:00:00 2001 -From: "Dr. Stephen Henson" -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 - -Upstream-Status: Backport -CVE: CVE-2016-6302 -Signed-off-by: Armin Kuster - ---- - ssl/t1_lib.c | 11 ++++++++--- - 1 file changed, 8 insertions(+), 3 deletions(-) - -Index: openssl-1.0.2h/ssl/t1_lib.c -=================================================================== ---- openssl-1.0.2h.orig/ssl/t1_lib.c -+++ openssl-1.0.2h/ssl/t1_lib.c -@@ -3397,9 +3397,7 @@ static int tls_decrypt_ticket(SSL *s, co - 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); -@@ -3433,6 +3431,13 @@ static int tls_decrypt_ticket(SSL *s, co - 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 diff --git a/recipes-connectivity/openssl/openssl/CVE-2016-6303.patch b/recipes-connectivity/openssl/openssl/CVE-2016-6303.patch deleted file mode 100644 index 95bdec4..0000000 --- a/recipes-connectivity/openssl/openssl/CVE-2016-6303.patch +++ /dev/null @@ -1,36 +0,0 @@ -From 1027ad4f34c30b8585592764b9a670ba36888269 Mon Sep 17 00:00:00 2001 -From: "Dr. Stephen Henson" -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 -(cherry picked from commit 55d83bf7c10c7b205fffa23fa7c3977491e56c07) - -Upstream-Status: Backport -CVE: CVE-2016-6303 -Signed-off-by: Armin Kuster - ---- - 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; --- -2.7.4 - diff --git a/recipes-connectivity/openssl/openssl/CVE-2016-6304.patch b/recipes-connectivity/openssl/openssl/CVE-2016-6304.patch deleted file mode 100644 index 64508b5..0000000 --- a/recipes-connectivity/openssl/openssl/CVE-2016-6304.patch +++ /dev/null @@ -1,75 +0,0 @@ -From ea39b16b71e4e72a228a4535bd6d6a02c5edbc1f Mon Sep 17 00:00:00 2001 -From: Matt Caswell -Date: Fri, 9 Sep 2016 10:08:45 +0100 -Subject: [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. - -Reviewed-by: Rich Salz - -Upstream-Status: Backport -CVE: CVE-2016-6304 -Signed-off-by: Armin Kuster - ---- - ssl/t1_lib.c | 24 +++++++++++++++++------- - 1 file changed, 17 insertions(+), 7 deletions(-) - -diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c -index fbcf2e6..e4b4e27 100644 ---- a/ssl/t1_lib.c -+++ b/ssl/t1_lib.c -@@ -2316,6 +2316,23 @@ static int ssl_scan_clienthello_tlsext(SSL *s, unsigned char **p, - size -= 2; - if (dsize > size) - goto err; -+ -+ /* -+ * We remove any OCSP_RESPIDs from a previous handshake -+ * to prevent unbounded memory growth - CVE-2016-6304 -+ */ -+ sk_OCSP_RESPID_pop_free(s->tlsext_ocsp_ids, -+ OCSP_RESPID_free); -+ if (dsize > 0) { -+ s->tlsext_ocsp_ids = sk_OCSP_RESPID_new_null(); -+ if (s->tlsext_ocsp_ids == NULL) { -+ *al = SSL_AD_INTERNAL_ERROR; -+ return 0; -+ } -+ } else { -+ s->tlsext_ocsp_ids = NULL; -+ } -+ - while (dsize > 0) { - OCSP_RESPID *id; - int idsize; -@@ -2335,13 +2352,6 @@ static int ssl_scan_clienthello_tlsext(SSL *s, unsigned char **p, - OCSP_RESPID_free(id); - goto err; - } -- if (!s->tlsext_ocsp_ids -- && !(s->tlsext_ocsp_ids = -- sk_OCSP_RESPID_new_null())) { -- OCSP_RESPID_free(id); -- *al = SSL_AD_INTERNAL_ERROR; -- return 0; -- } - if (!sk_OCSP_RESPID_push(s->tlsext_ocsp_ids, id)) { - OCSP_RESPID_free(id); - *al = SSL_AD_INTERNAL_ERROR; --- -2.7.4 - diff --git a/recipes-connectivity/openssl/openssl/CVE-2016-6306.patch b/recipes-connectivity/openssl/openssl/CVE-2016-6306.patch deleted file mode 100644 index 9e7d576..0000000 --- a/recipes-connectivity/openssl/openssl/CVE-2016-6306.patch +++ /dev/null @@ -1,71 +0,0 @@ -From ff553f837172ecb2b5c8eca257ec3c5619a4b299 Mon Sep 17 00:00:00 2001 -From: "Dr. Stephen Henson" -Date: Sat, 17 Sep 2016 12:36:58 +0100 -Subject: [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 - -Reviewed-by: Richard Levitte -Reviewed-by: Matt Caswell - -Upstream-Status: Backport -CVE: CVE-2016-6306 -Signed-off-by: Armin Kuster - ---- - ssl/s3_clnt.c | 11 +++++++++++ - ssl/s3_srvr.c | 6 ++++++ - 2 files changed, 17 insertions(+) - -Index: openssl-1.0.2h/ssl/s3_clnt.c -=================================================================== ---- openssl-1.0.2h.orig/ssl/s3_clnt.c -+++ openssl-1.0.2h/ssl/s3_clnt.c -@@ -1216,6 +1216,12 @@ int ssl3_get_server_certificate(SSL *s) - goto f_err; - } - for (nc = 0; nc < llen;) { -+ if (nc + 3 > llen) { -+ al = SSL_AD_DECODE_ERROR; -+ SSLerr(SSL_F_SSL3_GET_SERVER_CERTIFICATE, -+ SSL_R_CERT_LENGTH_MISMATCH); -+ goto f_err; -+ } - n2l3(p, l); - if ((l + nc + 3) > llen) { - al = SSL_AD_DECODE_ERROR; -@@ -2167,6 +2173,11 @@ int ssl3_get_certificate_request(SSL *s) - } - - for (nc = 0; nc < llen;) { -+ if (nc + 2 > llen) { -+ ssl3_send_alert(s, SSL3_AL_FATAL, SSL_AD_DECODE_ERROR); -+ SSLerr(SSL_F_SSL3_GET_CERTIFICATE_REQUEST, SSL_R_CA_DN_TOO_LONG); -+ goto err; -+ } - n2s(p, l); - if ((l + nc + 2) > llen) { - if ((s->options & SSL_OP_NETSCAPE_CA_DN_BUG)) -Index: openssl-1.0.2h/ssl/s3_srvr.c -=================================================================== ---- openssl-1.0.2h.orig/ssl/s3_srvr.c -+++ openssl-1.0.2h/ssl/s3_srvr.c -@@ -3213,6 +3213,12 @@ int ssl3_get_client_certificate(SSL *s) - goto f_err; - } - for (nc = 0; nc < llen;) { -+ if (nc + 3 > llen) { -+ al = SSL_AD_DECODE_ERROR; -+ SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE, -+ SSL_R_CERT_LENGTH_MISMATCH); -+ goto f_err; -+ } - n2l3(p, l); - if ((l + nc + 3) > llen) { - al = SSL_AD_DECODE_ERROR; diff --git a/recipes-connectivity/openssl/openssl_1.0.2h.bbappend b/recipes-connectivity/openssl/openssl_1.0.2h.bbappend deleted file mode 100644 index 0f635bf..0000000 --- a/recipes-connectivity/openssl/openssl_1.0.2h.bbappend +++ /dev/null @@ -1,14 +0,0 @@ -FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" - -SRC_URI += "file://CVE-2016-2178.patch \ - file://CVE-2016-2179.patch \ - file://CVE-2016-2180.patch \ - file://CVE-2016-2181_p1.patch \ - file://CVE-2016-2181_p2.patch \ - file://CVE-2016-2181_p3.patch \ - file://CVE-2016-2182.patch \ - file://CVE-2016-6302.patch \ - file://CVE-2016-6303.patch \ - file://CVE-2016-6304.patch \ - file://CVE-2016-6306.patch \ - " -- cgit v1.2.3-54-g00ecf