Three vulnerabilities have been fixed with new openssl versions: SSL, TLS and DTLS Plaintext Recovery Attack (CVE-2013-0169) TLS 1.1 and 1.2 AES-NI crash (CVE-2012-2686) OCSP invalid key DoS issue (CVE-2013-0166) Regarding the first (CVE-2013-0169), the underlying problem is the weakness of the AES-CBC modes. As the only proper solution to that is to switch to TLS 1.2, I'd suggest we should advise users to switch to the 1.0.1-version if possible (1.0.0 and before don't support TLS 1.2). Stabilization of 1.0.1 is already happening in #454566.
Commit message: Version bump http://sources.gentoo.org/dev-libs/openssl/openssl-0.9.8y.ebuild?rev=1.1 http://sources.gentoo.org/dev-libs/openssl/openssl-1.0.1d.ebuild?rev=1.1
*** Bug 455556 has been marked as a duplicate of this bug. ***
There seems to be a major regression in 1.0.1d (various bugs popping up), and openssl upstream intends to ship another release soon. This is the supposedly fixing commit: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247 I suggest waiting with stabilization for another openssl release.
I've temporarily added 1.0.1d to package.mask (bug #456108). Sorry if that causes any inconvenience.
1.0.1e is available upstream now.
Thanks, Mike, Hanno, and Ryan. Are these ready for stabilization? =dev-libs/openssl-0.9.8y =dev-libs/openssl-1.0.1e
CVE-2013-0169 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-0169): The TLS protocol 1.1 and 1.2 and the DTLS protocol 1.0 and 1.2, as used in OpenSSL, OpenJDK, PolarSSL, and other products, do not properly consider timing side-channel attacks on a MAC check requirement during the processing of malformed CBC padding, which allows remote attackers to conduct distinguishing attacks and plaintext-recovery attacks via statistical analysis of timing data for crafted packets, aka the "Lucky Thirteen" issue. CVE-2013-0166 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-0166): OpenSSL before 0.9.8y, 1.0.0 before 1.0.0k, and 1.0.1 before 1.0.1d does not properly perform signature verification for OCSP responses, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via an invalid key. CVE-2012-2686 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-2686): crypto/evp/e_aes_cbc_hmac_sha1.c in the AES-NI functionality in the TLS 1.1 and 1.2 implementations in OpenSSL 1.0.1 before 1.0.1d allows remote attackers to cause a denial of service (application crash) via crafted CBC data.
What's holding this up? Is 1.0.0e ready for stabilization?
Sorry, I meant 1.0.1e.
Are we still waiting for something here?
Can please someone from security or openssl maintainers react here? This is a security bug, it seems its fixed since several months, just stabilization is waiting (so probably just cc arch's, I won't do it as I understand it that this is maintainers or security teams job). Weird enough, it seems a bunch of stabilizations happened on an old, vulnerable openssl version in the meantime.
(In reply to Sean Amoss from comment #6) > Thanks, Mike, Hanno, and Ryan. Are these ready for stabilization? > > =dev-libs/openssl-0.9.8y > =dev-libs/openssl-1.0.1e base-system: ^ Likely 1.0.1e-r1 should be stabled now. Let's finally do that in a week if there is no feedback.
Timeout. Arches, please test and stabilize: =dev-libs/openssl-0.9.8y Target arches: amd64 x86 =dev-libs/openssl-1.0.1e Target arches: alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86
Sorry, should have been 1.0.1e-r1. Correct stable list: =dev-libs/openssl-0.9.8y Target arches: amd64 x86 =dev-libs/openssl-1.0.1e-r1 Target arches: alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86
Stable for HPPA.
amd64 stable
x86 stable
ppc stable
ppc64 stable
arm stable
ia64 stable
alpha stable
Im able to reprdoduce bug 69976 on ppc64, see comment #19. I've update portage with ppc64 stable for openssl-1.0.1e and ~ppc64 for openssl-1.0.1e-r1
SH is not anymore a stable arch, removing it from the cc list
S390 is not anymore a stable arch, removing it from the cc list
M68K is not anymore a stable arch, removing it from the cc list
sparc stable
Added to existing GLSA draft. @maintainers: cleanup, please
+ 26 Nov 2013; Lars Wendler <polynomial-c@gentoo.org> -openssl-0.9.8u.ebuild, + -openssl-0.9.8v.ebuild, -openssl-0.9.8w.ebuild, -openssl-0.9.8x.ebuild, + -openssl-1.0.0h.ebuild, -openssl-1.0.0i.ebuild, -openssl-1.0.1a.ebuild, + -openssl-1.0.1b.ebuild, -openssl-1.0.1c.ebuild, -openssl-1.0.1d.ebuild, + -openssl-1.0.1d-r1.ebuild, openssl-1.0.1e.ebuild, + -files/openssl-1.0.0d-alpha-fix-unalign.patch, + -files/openssl-1.0.0d-alpha-typo.patch, + -files/openssl-1.0.0e-pkg-config.patch, -files/openssl-1.0.1-ipv6.patch, + -files/openssl-1.0.1a-hmac-ia32cap.patch, + -files/openssl-1.0.1d-s3-packet.patch: + Removed old vulnerable versions. Removed all but ppc64 KEYWORDS from + openssl-1.0.1e.ebuild. + I hope I got all versions except of openssl-1.0.1e.ebuild which is the latest ebuild being stable for ppc64.
This issue was resolved and addressed in GLSA 201312-03 at http://security.gentoo.org/glsa/glsa-201312-03.xml by GLSA coordinator Chris Reffett (creffett).