Re: [OE-core] [PATCH 1/1] openssl: update to 1.0.2i (CVE-2016-6304 and more)

2016-09-26 Thread Alexander Kanavin 

On 09/23/2016 07:25 PM, akuster808 wrote:


No this demonstrates that folks do want to help out. They to the best
they can with their abilities and situation. The community has made a
lot of noise about how important it is to address security issues.
Except a few of us who do send patches, the community as a whole does
not stepped up to the table to help out.

Opensource is not an all or nothing proposition. I for one appreciate
contributions folks make in this area.


If folks want to help out, they'd better spend their time building 
automated CI infrastructure that allows us to upgrade openssl to 1.0.2j 
in stable releases without the paralyzing fear of breaking things. I 
appreciate the intent to help, but I don't see the actual contribution 
(of randomly backporting CVEs) as particularly useful in the long run.



Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] openssl: update to 1.0.2i (CVE-2016-6304 and more)

2016-09-23 Thread akuster808 



On 09/23/2016 05:01 AM, Alexander Kanavin wrote:

On 09/23/2016 11:39 AM, Patrick Ohly wrote:

This update fixes several CVEs:
* OCSP Status Request extension unbounded memory growth (CVE-2016-6304)
* SWEET32 Mitigation (CVE-2016-2183)
* OOB write in MDC2_Update() (CVE-2016-6303)
* Malformed SHA512 ticket DoS (CVE-2016-6302)
* OOB write in BN_bn2dec() (CVE-2016-2182)
* OOB read in TS_OBJ_print_bio() (CVE-2016-2180)
* DTLS buffered message DoS (CVE-2016-2179)
* DTLS replay protection DoS (CVE-2016-2181)
* Certificate message OOB reads (CVE-2016-6306)

Of these, only CVE-2016-6304 is considered of high
severity. Everything else is low. CVE-2016-2177 and CVE-2016-2178 were
already fixed via local patches, which can be removed now.


This demonstrates that:

a) if CVEs are fixed with backported patches, the process must be 
*thorough* and not shotgun-ish like now. It's pointless to fix some 
CVEs and ignore the others, just because that's what automated tools 
like cve-checker reported or someone saw some mail on a mailing list.


b) it's okay to not fix low-severity CVEs until the upstream makes a 
new release. Upstream is much more competent than we are to judge 
that, and if the issue is high severity, they should make a new 
release anyway.


No this demonstrates that folks do want to help out. They to the best 
they can with their abilities and situation. The community has made a 
lot of noise about how important it is to address security issues. 
Except a few of us who do send patches, the community as a whole does 
not stepped up to the table to help out.


Opensource is not an all or nothing proposition. I for one appreciate 
contributions folks make in this area.


- Armin




Please feel free to disagree.

Alex


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] openssl: update to 1.0.2i (CVE-2016-6304 and more)

2016-09-23 Thread Alexander Kanavin 

On 09/23/2016 11:39 AM, Patrick Ohly wrote:

This update fixes several CVEs:
* OCSP Status Request extension unbounded memory growth (CVE-2016-6304)
* SWEET32 Mitigation (CVE-2016-2183)
* OOB write in MDC2_Update() (CVE-2016-6303)
* Malformed SHA512 ticket DoS (CVE-2016-6302)
* OOB write in BN_bn2dec() (CVE-2016-2182)
* OOB read in TS_OBJ_print_bio() (CVE-2016-2180)
* DTLS buffered message DoS (CVE-2016-2179)
* DTLS replay protection DoS (CVE-2016-2181)
* Certificate message OOB reads (CVE-2016-6306)

Of these, only CVE-2016-6304 is considered of high
severity. Everything else is low. CVE-2016-2177 and CVE-2016-2178 were
already fixed via local patches, which can be removed now.


This demonstrates that:

a) if CVEs are fixed with backported patches, the process must be 
*thorough* and not shotgun-ish like now. It's pointless to fix some CVEs 
and ignore the others, just because that's what automated tools like 
cve-checker reported or someone saw some mail on a mailing list.


b) it's okay to not fix low-severity CVEs until the upstream makes a new 
release. Upstream is much more competent than we are to judge that, and 
if the issue is high severity, they should make a new release anyway.


Please feel free to disagree.

Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/1] openssl: update to 1.0.2i (CVE-2016-6304 and more)

2016-09-23 Thread Patrick Ohly 
This update fixes several CVEs:
* OCSP Status Request extension unbounded memory growth (CVE-2016-6304)
* SWEET32 Mitigation (CVE-2016-2183)
* OOB write in MDC2_Update() (CVE-2016-6303)
* Malformed SHA512 ticket DoS (CVE-2016-6302)
* OOB write in BN_bn2dec() (CVE-2016-2182)
* OOB read in TS_OBJ_print_bio() (CVE-2016-2180)
* DTLS buffered message DoS (CVE-2016-2179)
* DTLS replay protection DoS (CVE-2016-2181)
* Certificate message OOB reads (CVE-2016-6306)

Of these, only CVE-2016-6304 is considered of high
severity. Everything else is low. CVE-2016-2177 and CVE-2016-2178 were
already fixed via local patches, which can be removed now.

See https://www.openssl.org/news/secadv/20160922.txt for details.

Some patches had to be refreshed and one compile error fix from
upstream's OpenSSL_1_0_2-stable was required.

Signed-off-by: Patrick Ohly 
---
 .../openssl/openssl/CVE-2016-2177.patch| 286 -
 .../openssl/openssl/CVE-2016-2178.patch|  51 
 .../openssl/Fix-typo-introduced-by-a03f81f4.patch  |  29 +++
 .../openssl/openssl/debian/ca.patch|   2 +-
 .../openssl/openssl/parallel.patch |  17 +-
 .../{openssl_1.0.2h.bb => openssl_1.0.2i.bb}   |   7 +-
 6 files changed, 47 insertions(+), 345 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/openssl/openssl/CVE-2016-2177.patch
 delete mode 100644 
meta/recipes-connectivity/openssl/openssl/CVE-2016-2178.patch
 create mode 100644 
meta/recipes-connectivity/openssl/openssl/Fix-typo-introduced-by-a03f81f4.patch
 rename meta/recipes-connectivity/openssl/{openssl_1.0.2h.bb => 
openssl_1.0.2i.bb} (91%)

diff --git a/meta/recipes-connectivity/openssl/openssl/CVE-2016-2177.patch 
b/meta/recipes-connectivity/openssl/openssl/CVE-2016-2177.patch
deleted file mode 100644
index df36d5f..000
--- a/meta/recipes-connectivity/openssl/openssl/CVE-2016-2177.patch
+++ /dev/null
@@ -1,286 +0,0 @@
-From a004e72b95835136d3f1ea90517f706c24c03da7 Mon Sep 17 00:00:00 2001
-From: Matt Caswell 
-Date: Thu, 5 May 2016 11:10:26 +0100
-Subject: [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
-
-Reviewed-by: Rich Salz 
-
-Upstream-Status: Backport
-CVE: CVE-2016-2177
-
-Signed-off-by: Armin Kuster 
-
-

- ssl/s3_srvr.c  | 14 +++---
- ssl/ssl_sess.c |  2 +-
- ssl/t1_lib.c   | 56 ++--
- 3 files changed, 38 insertions(+), 34 deletions(-)
-
-diff --git a/ssl/s3_srvr.c b/ssl/s3_srvr.c
-index ab28702..ab7f690 100644
 a/ssl/s3_srvr.c
-+++ b/ssl/s3_srvr.c
-@@ -980,7 +980,7 @@ int ssl3_get_client_hello(SSL *s)
- 
- session_length = *(p + SSL3_RANDOM_SIZE);
- 
--if (p + SSL3_RANDOM_SIZE + session_length + 1 >= d + n) {
-+if (SSL3_RANDOM_SIZE + session_length + 1 >= (d + n) - p) {
- al = SSL_AD_DECODE_ERROR;
- SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, SSL_R_LENGTH_TOO_SHORT);
- goto f_err;
-@@ -998,7 +998,7 @@ int ssl3_get_client_hello(SSL *s)
- /* get the session-id */
- j = *(p++);
- 
--if (p + j > d + n) {
-+if ((d + n) - p < j) {
- al = SSL_AD_DECODE_ERROR;
- SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, SSL_R_LENGTH_TOO_SHORT);
- goto f_err;
-@@ -1054,14 +1054,14 @@ int ssl3_get_client_hello(SSL *s)
- 
- if (SSL_IS_DTLS(s)) {
- /* cookie stuff */
--if (p + 1 > d + n) {
-+if ((d + n) - p < 1) {
- al = SSL_AD_DECODE_ERROR;
- SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, SSL_R_LENGTH_TOO_SHORT);
- goto f_err;
- }
- cookie_len = *(p++);
- 
--if (p + cookie_len > d + n) {
-+if ((d + n ) - p < cookie_len) {
- al = SSL_AD_DECODE_ERROR;
- SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, SSL_R_LENGTH_TOO_SHORT);
- goto f_err;
-@@ -1131,7 +1131,7 @@ int ssl3_get_client_hello(SSL *s)
- }
- }
- 
--if (p + 2 > d + n) {
-+if ((d + n ) - p < 2) {
- al = SSL_AD_DECODE_ERROR;
- SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO, SSL_R_LENGTH_TOO_SHORT);
- goto f_err;
-@@ -1145,7 +1145,7 @@ int ssl3_get_client_hello(SSL *s)
- }
- 
- /* i bytes of cipher data + 1 byte for compression