Six issues have been fixed within openssl 1.0.0f and 0.9.8s: DTLS Plaintext Recovery Attack (CVE-2011-4108) Double-free in Policy Checks (CVE-2011-4109) Uninitialized SSL 3.0 Padding (CVE-2011-4576) Malformed RFC 3779 Data Can Cause Assertion Failures (CVE-2011-4577) SGC Restart DoS Attack (CVE-2011-4619) Invalid GOST parameters DoS Attack (CVE-2012-0027) From http://openssl.org/news/secadv_20120104.txt
both versions now in the tree
Thanks, and apologies for the bugspam. Arches, please test and mark stable: =dev-libs/openssl-1.0.0f Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86" =dev-libs/openssl-0.9.8s Target keywords : "amd64 x86"
Needs =sys-libs/zlib-1.2.5.1-r2 too.
amd64 ok
(In reply to comment #3) > Needs > =sys-libs/zlib-1.2.5.1-r2 > too. I doubt everything in ~arch even builds against this version yet, due to the gentoo specific "OF" macro change Enough to stop any stabilization(s) for now
CVE-2012-0027 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2012-0027): The GOST ENGINE in OpenSSL before 1.0.0f does not properly handle invalid parameters for the GOST block cipher, which allows remote attackers to cause a denial of service (daemon crash) via crafted data from a TLS client. CVE-2011-4619 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-4619): The Server Gated Cryptography (SGC) implementation in OpenSSL before 0.9.8s and 1.x before 1.0.0f does not properly handle handshake restarts, which allows remote attackers to cause a denial of service via unspecified vectors. CVE-2011-4577 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-4577): OpenSSL before 0.9.8s and 1.x before 1.0.0f, when RFC 3779 support is enabled, allows remote attackers to cause a denial of service (assertion failure) via an X.509 certificate containing certificate-extension data associated with (1) IP address blocks or (2) Autonomous System (AS) identifiers. CVE-2011-4576 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-4576): The SSL 3.0 implementation in OpenSSL before 0.9.8s and 1.x before 1.0.0f does not properly initialize data structures for block cipher padding, which might allow remote attackers to obtain sensitive information by decrypting the padding data sent by an SSL peer. CVE-2011-4109 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-4109): Double free vulnerability in OpenSSL 0.9.8 before 0.9.8s, when X509_V_FLAG_POLICY_CHECK is enabled, allows remote attackers to have an unspecified impact by triggering failure of a policy check. CVE-2011-4108 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-4108): The DTLS implementation in OpenSSL before 0.9.8s and 1.x before 1.0.0f performs a MAC check only if certain padding is valid, which makes it easier for remote attackers to recover plaintext via a padding oracle attack.
amd64: ok
(In reply to comment #5) > I doubt everything in ~arch even builds against this version yet, due to the > gentoo specific "OF" macro change > > Enough to stop any stabilization(s) for now Ok, if the stabilization is blocked, no need arch teams here.
Adding depend on 384483, please correct if there is a more appropriate bug to track. Thanks. Or, is there a way in which we can fix these security issues with the current stable zlib?
openssl-0.9.8s has never needed =sys-libs/zlib-1.2.5.1-r2 openssl-1.0.0f did need newer zlib, but that's fixed in 1.0.0f-r1. no reason to not stable things now then. targets: 0.9.8s-r1 1.0.0f-r1
(In reply to comment #10) > openssl-0.9.8s has never needed =sys-libs/zlib-1.2.5.1-r2 > > openssl-1.0.0f did need newer zlib, but that's fixed in 1.0.0f-r1. no reason > to not stable things now then. > > targets: 0.9.8s-r1 1.0.0f-r1 great, thanks. Arches, please test and mark stable: =dev-libs/openssl-1.0.0f-r1 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86" =dev-libs/openssl-0.9.8s-r1 Target keywords : "amd64 x86"
amd64 stable.
Stable for HPPA.
x86 stable
alpha/arm/ia64/m68k/s390/sh/sparc stable
ppc/ppc64 done
Thanks everyone, filed new glsa request.
Outdated by Bug #399365
This issue was resolved and addressed in GLSA 201203-12 at http://security.gentoo.org/glsa/glsa-201203-12.xml by GLSA coordinator Sean Amoss (ackle).