Summary: | <dev-libs/openssl-{0.9.8y,1.0.1e-r1} : multiple vulnerabilities (CVE-2012-2686,CVE-2013-{0166,0169}) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Hanno Böck <hanno> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system, rhill |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://www.openssl.org/news/secadv_20130205.txt | ||
Whiteboard: | A3 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Hanno Böck
2013-02-05 13:14:48 UTC
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). |