OpenSSL Security Advisory [3 Dec 2015] ======================================= NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE 0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS. BN_mod_exp may produce incorrect results on x86_64 (CVE-2015-3193) ================================================================== Severity: Moderate There is a carry propagating bug in the x86_64 Montgomery squaring procedure. No EC algorithms are affected. Analysis suggests that attacks against RSA and DSA as a result of this defect would be very difficult to perform and are not believed likely. Attacks against DH are considered just feasible (although very difficult) because most of the work necessary to deduce information about a private key may be performed offline. The amount of resources required for such an attack would be very significant and likely only accessible to a limited number of attackers. An attacker would additionally need online access to an unpatched system using the target private key in a scenario with persistent DH parameters and a private key that is shared between multiple clients. For example this can occur by default in OpenSSL DHE based SSL/TLS ciphersuites. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2e This issue was reported to OpenSSL on August 13 2015 by Hanno Böck. The fix was developed by Andy Polyakov of the OpenSSL development team. Certificate verify crash with missing PSS parameter (CVE-2015-3194) =================================================================== Severity: Moderate The signature verification routines will crash with a NULL pointer dereference if presented with an ASN.1 signature using the RSA PSS algorithm and absent mask generation function parameter. Since these routines are used to verify certificate signature algorithms this can be used to crash any certificate verification operation and exploited in a DoS attack. Any application which performs certificate verification is vulnerable including OpenSSL clients and servers which enable client authentication. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q This issue was reported to OpenSSL on August 27 2015 by Loïc Jonas Etienne (Qnective AG). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. X509_ATTRIBUTE memory leak (CVE-2015-3195) ========================================== Severity: Moderate When presented with a malformed X509_ATTRIBUTE structure OpenSSL will leak memory. This structure is used by the PKCS#7 and CMS routines so any application which reads PKCS#7 or CMS data from untrusted sources is affected. SSL/TLS is not affected. This issue affects OpenSSL versions 1.0.2 and 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.2 users should upgrade to 1.0.2e OpenSSL 1.0.1 users should upgrade to 1.0.1q OpenSSL 1.0.0 users should upgrade to 1.0.0t OpenSSL 0.9.8 users should upgrade to 0.9.8zh This issue was reported to OpenSSL on November 9 2015 by Adam Langley (Google/BoringSSL) using libFuzzer. The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Race condition handling PSK identify hint (CVE-2015-3196) ========================================================= Severity: Low If PSK identity hints are received by a multi-threaded client then the values are wrongly updated in the parent SSL_CTX structure. This can result in a race condition potentially leading to a double free of the identify hint data. This issue was fixed in OpenSSL 1.0.2d and 1.0.1p but has not been previously listed in an OpenSSL security advisory. This issue also affects OpenSSL 1.0.0 and has not been previously fixed in an OpenSSL 1.0.0 release. OpenSSL 1.0.2 users should upgrade to 1.0.2d OpenSSL 1.0.1 users should upgrade to 1.0.1p OpenSSL 1.0.0 users should upgrade to 1.0.0t The fix for this issue can be identified in the OpenSSL git repository by commit ids 3c66a669dfc7 (1.0.2), d6be3124f228 (1.0.1) and 1392c238657e (1.0.0). The fix was developed by Dr. Stephen Henson of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these versions will be provided after that date. In the absence of significant security issues being identified prior to that date, the 1.0.0t and 0.9.8zh releases will be the last for those versions. Users of these versions are advised to upgrade.
Working on the bumps...
(In reply to Lars Wendler (Polynomial-C) from comment #1) there wasn't a bug when i started ;) http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3db5c05c662167d9b25fb6d7404663a9a5138fe7
we aren't bothering with 1.0.[01] anymore since 1.0.2 covers the same ABI and is already in stable
Please be aware that upstream is acting like a fool and replaced the release files in-place c.f. https://mta.openssl.org/pipermail/openssl-announce/2015-December/000051.html.
(In reply to Kristian Fiskerstrand from comment #4) i've uploaded the new ones to dev for pushing to the mirrors updated the main tree now too: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=88560c8e2a93aad3fa621c286e4adf651b119870
(In reply to SpanKY from comment #5) > (In reply to Kristian Fiskerstrand from comment #4) > > i've uploaded the new ones to dev for pushing to the mirrors > Thanks. Has this been tested sufficiently to stabilize it? I haven't encountered any issues on my own systems at least* * as long as the fresh dep on =app-misc/c_reshash-1.7-r1 is installed simultaneously anyways, so this will have to be stabilized along with it.
OpenSSL Security Advisory [3 Dec 2015] - Updated [4 Dec 2015] ============================================================= [Updated 4 Dec 2015]: This advisory has been updated to include the details of CVE-2015-1794, a Low severity issue affecting OpenSSL 1.0.2 which had a fix included in the released packages but was missed from the advisory text. Anon DH ServerKeyExchange with 0 p parameter (CVE-2015-1794) ============================================================ Severity: Low If a client receives a ServerKeyExchange for an anonymous DH ciphersuite with the value of p set to 0 then a seg fault can occur leading to a possible denial of service attack. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2e This issue was reported to OpenSSL on August 3 2015 by Guy Leaver (Cisco). The fix was developed by Matt Caswell of the OpenSSL development team.
(In reply to Kristian Fiskerstrand from comment #6) should be fine to stabilize it all. the diff between the two vers doesn't look that scary.
(In reply to SpanKY from comment #8) > (In reply to Kristian Fiskerstrand from comment #6) > > should be fine to stabilize it all. the diff between the two vers doesn't > look that scary. Arches, please stabilize =app-misc/c_rehash-1.7-r1 =dev-libs/openssl-1.0.2e Stable targets: alpha amd64 arm hppa ia64 ppc64 ppc sparc x86
Stable for HPPA PPC64.
(In reply to Kristian Fiskerstrand from comment #9) > (In reply to SpanKY from comment #8) > > (In reply to Kristian Fiskerstrand from comment #6) > > > > should be fine to stabilize it all. the diff between the two vers doesn't > > look that scary. > > Arches, please stabilize > =app-misc/c_rehash-1.7-r1 > =dev-libs/openssl-1.0.2e > Stable targets: alpha amd64 arm hppa ia64 ppc64 ppc sparc x86 The bug title implies we should be stabilizing =dev-libs/openssl-0.9.8z as well. Should we?
alpha stable (please re-Cc if we need to stabilize =dev-libs/openssl-0.9.8z_p8)
(In reply to Matt Turner from comment #11) > The bug title implies we should be stabilizing =dev-libs/openssl-0.9.8z as > well. Should we? CVE-2015-3195 reports 0.9.8 as affected, so yes.
amd64 stable
(In reply to Agostino Sarubbo from comment #13) we can probably drop stable from 0.9.8 and see if anyone cares
arm stable
ia64 stable
arm64/m68k/s390/sh/sparc/x86 stable
ppc stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
(In reply to SpanKY from comment #15) > (In reply to Agostino Sarubbo from comment #13) > > we can probably drop stable from 0.9.8 and see if anyone cares for now, from my searches, I guess you can drop the old version and keep the latest version stable only for amd64/x86.
Can we please Mask 0.9.8z_p7 since it will pull in vulnerable version for everything but amd64/x86?
Adding additional CVE. This will assist when determining what versions to cleanup CVE-2015-3197: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2015-3197 ssl/s2_srvr.c in OpenSSL 1.0.1 before 1.0.1r and 1.0.2 before 1.0.2f does not prevent use of disabled ciphers, which makes it easier for man-in-the-middle attackers to defeat cryptographic protection mechanisms by performing computations on SSLv2 traffic, related to the get_client_master_key and get_client_hello functions.
Thankfully the versions are lining up but here is another CVE: CVE-2016-0701: https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-0701 The DH_check_pub_key function in crypto/dh/dh_check.c in OpenSSL 1.0.2 before 1.0.2f does not ensure that prime numbers are appropriate for Diffie-Hellman (DH) key exchange, which makes it easier for remote attackers to discover a private DH exponent by making multiple handshakes with a peer that chose an inappropriate number, as demonstrated by a number in an X9.42 file.
(In reply to Aaron Bauman from comment #23) > Thankfully the versions are lining up but here is another CVE: > > CVE-2016-0701: > [..] Thanks for the effort, but CVE-2015-3197 and CVE-2016-0701 were handled in bug 572854. Unfortunately, we missed the bug at hand when we released GLSA 201601-05. I suppose in order to avoid confusing people, we can just retroactively add this bug to GLSA 201601-05.
I have added the CVEs to GLSA 201601-05 now. The 1.0.1 and 1.0.2 versions already superseded the ones here, so I only added the unaffected versions for 0.9.8. Only cleanup remaining.
So based on this we need to remove: - 0.9.8z_p7 - 1.0.1p - 1.0.1r - 1.0.2e I'll do 1.0.1p, 1.0.1r and 1.0.2e as one commit and then 0.9.8z_p7 as another commit in case we need to bring it back though we'd probably just say stabilize 0.9.8z_p8 instead.
Thanks for the report. re: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e47b9611f34d6141b0e389e94e0b84135afa25ba
Thanks for the report. re: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=47f53172d2f6e2beaddb1c072d62e51de3884111
Cleanup complete and bug was added to previous GLSA per previous comments. This issue was resolved and addressed in GLSA 201601-05 at https://security.gentoo.org/glsa/201601-05 by GLSA coordinator Tobias Heinlein (keytoaster).
