This is a complex set of vulenerabilities. The recommended versions are: 0.9.8za 1.0.0m 1.0.1h More details at $URL.
+*openssl-1.0.1h (05 Jun 2014) +*openssl-1.0.0m (05 Jun 2014) + + 05 Jun 2014; Lars Wendler <polynomial-c@gentoo.org> +openssl-1.0.0m.ebuild, + +openssl-1.0.1h.ebuild, +files/openssl-1.0.1h-ipv6.patch: + Security bump (bug #512506). + I didn't add openssl-0.9.8za as that one breaks portage's ebuild naming scheme. Since this IMHO only affects some older lib32 packages, I leave that one of somebody else to commit.
Please note "A buffer overrun attack can be triggered by sending invalid DTLS fragments to an OpenSSL DTLS client or server. This is potentially exploitable to run arbitrary code on a vulnerable client or server." in CVE-2014-0195 wrt Rating.
Changing rating to A2 after discussion with creffett
Arches, please stabilize =dev-libs/openssl-1.0.1h Targets: alpha amd64 arm arm64 hppa ia64 m68k ppc ppc64 s390 sh sparc x86 Note that 0.9.8 will have to be stabilized afterwards, requesting stabilization of the 1.0.1 branch specifically after discussing with Chainsaw
+*openssl-1.0.1h-r2 (05 Jun 2014) +*openssl-1.0.1h-r1 (05 Jun 2014) + + 05 Jun 2014; Tony Vroon <chainsaw@gentoo.org> -openssl-1.0.1h.ebuild, + +openssl-1.0.1h-r1.ebuild, +openssl-1.0.1h-r2.ebuild: + Decouple 1.0.1H security upgrade from experimental multilib portation with + broken dependency tree. Your security upgrade is R1 and your experiment is + R2. Can we please not do that again.
+ 05 Jun 2014; Tony Vroon <chainsaw@gentoo.org> openssl-1.0.1h-r1.ebuild: + Stabilising 1.0.1H on AMD64 based on infra field testing by Jorge Manuel B. + S. Vicetto and additional testing by Kristian Fiskerstrand. For security bug + #512506; expedited due to operational needs.
Sorry about erronuous details in comment 4. also updating to -r1 due to multilib issue with the last 1.0.1h package. Trying again Arches, please stabilize =dev-libs/openssl-1.0.1h-r1 Targets: alpha amd64 arm arm64 hppa ia64 ppc ppc64 sparc x86 Note that 0.9.8 and 1.0.0 will have to be stabilized later.
Stabilized -r1 on alpha.
Stable for HPPA.
x86 stable
arm stable
*** Bug 509608 has been marked as a duplicate of this bug. ***
done all the rest
$ fgrep openssl */*/*.ebuild | egrep 'openssl[-:]0.9.8' | egrep '(\s|<)=|:0\.9\.8' app-emulation/emul-linux-x86-baselibs/emul-linux-x86-baselibs-20140508-r5.ebuild: >=dev-libs/openssl-0.9.8y-r1:0.9.8[abi_x86_32(-)] app-emulation/emul-linux-x86-baselibs/emul-linux-x86-baselibs-20140508-r6.ebuild: >=dev-libs/openssl-0.9.8y-r1:0.9.8[abi_x86_32(-)] app-emulation/vmware-player/vmware-player-5.0.3.1410761.ebuild: =dev-libs/openssl-0.9.8* app-emulation/vmware-player/vmware-player-6.0.1.1379776.ebuild: =dev-libs/openssl-0.9.8* app-emulation/vmware-player/vmware-player-6.0.2.1744117.ebuild: =dev-libs/openssl-0.9.8* app-emulation/vmware-vix/vmware-vix-1.11.4.744019.ebuild: =dev-libs/openssl-0.9.8* app-emulation/vmware-workstation/vmware-workstation-10.0.1.1379776-r1.ebuild: =dev-libs/openssl-0.9.8* app-emulation/vmware-workstation/vmware-workstation-10.0.2.1744117.ebuild: =dev-libs/openssl-0.9.8* app-emulation/vmware-workstation/vmware-workstation-9.0.3.1410761.ebuild: =dev-libs/openssl-0.9.8* app-text/acroread/acroread-9.5.5.ebuild: x86? ( =dev-libs/openssl-0.9.8* ) net-misc/nxclient/nxclient-3.5.0.7.ebuild: =dev-libs/openssl-0.9.8* sci-electronics/eagle/eagle-5.10.0-r1.ebuild: =dev-libs/openssl-0.9.8* ) sci-electronics/eagle/eagle-5.11.0.ebuild: =dev-libs/openssl-0.9.8* )
CVE-2014-3470 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-3470): The ssl3_send_client_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h, when an anonymous ECDH cipher suite is used, allows remote attackers to cause a denial of service (NULL pointer dereference and client crash) by triggering a NULL certificate value. CVE-2014-0224 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-0224): OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCipherSpec messages, which allows man-in-the-middle attackers to trigger use of a zero-length master key in certain OpenSSL-to-OpenSSL communications, and consequently hijack sessions or obtain sensitive information, via a crafted TLS handshake, aka the "CCS Injection" vulnerability. CVE-2014-0221 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-0221): The dtls1_get_message_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h allows remote attackers to cause a denial of service (recursion and client crash) via a DTLS hello message in an invalid DTLS handshake. CVE-2014-0198 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-0198): The do_ssl3_write function in s3_pkt.c in OpenSSL 1.x through 1.0.1g, when SSL_MODE_RELEASE_BUFFERS is enabled, does not properly manage a buffer pointer during certain recursive calls, which allows remote attackers to cause a denial of service (NULL pointer dereference and application crash) via vectors that trigger an alert condition. CVE-2014-0195 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-0195): The dtls1_reassemble_fragment function in d1_both.c in OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly validate fragment lengths in DTLS ClientHello messages, which allows remote attackers to execute arbitrary code or cause a denial of service (buffer overflow and application crash) via a long non-initial fragment.
CVE-2010-5298 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-5298): Race condition in the ssl3_read_bytes function in s3_pkt.c in OpenSSL through 1.0.1g, when SSL_MODE_RELEASE_BUFFERS is enabled, allows remote attackers to inject data across sessions or cause a denial of service (use-after-free and parsing error) via an SSL connection in a multithreaded environment.
(In reply to SpanKY from comment #13) > done all the rest Is this done for 0.9.8 and 1.0.0 as they were to be stabilized later.
(In reply to Yury German from comment #17) > Is this done for 0.9.8 and 1.0.0 as they were to be stabilized later. 0.9.8za does not fit our versioning schemas as defined in PMS and thus cannot be put in the tree. There is a lot of closed vendor stuff (VMware, yes...) depending on this so we may need to find a way to bodge it. This is a security bug so let's be brief. Someone find a way and commit it please?
How about just bringing it in as 0.9.8z-rX to get things moving?
Not to add more noise, but need to add this CVE as it is also covered by 0.9.8za and 1.0.0m CVE-2014-0076: Fix for the attack described in the paper "Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack" Reported by Yuval Yarom and Naomi Benger. This issue was previously fixed in OpenSSL 1.0.1g.
Regarding the 0.9.8za issue: -rX could turn problematic later when one couldn't make a difference between an ebuild change andn openssl version change. I thing using the _pX suffix would do a better job: 0.9.8z_p1 would mean 0.9.8za ... 0.9.8z_p25 would mean 0.9.8zy One would build a generic arithmetic for the above rule to automatically convert tarball filenames from ebuild names.
(In reply to Zoltán Halassy from comment #21) > Regarding the 0.9.8za issue: > ... > I thing using the _pX suffix would do a better job: > > 0.9.8z_p1 would mean 0.9.8za > 0.9.8z_p25 would mean 0.9.8zy > I like this approach. Would be appreciated if anyone can bring a build of 0.9.8za into the tree.
+*openssl-0.9.8z_p1 (15 Jun 2014) + + 15 Jun 2014; Tony Vroon <chainsaw@gentoo.org> +openssl-0.9.8z_p1.ebuild: + Add 0.9.8za using the version number adaptation suggested by Zoltán Halassy + in security bug #512506. Arches, please test & mark stable: =dev-libs/openssl-0.9.8z_p1 =dev-libs/openssl-1.0.0m Targets: alpha amd64 arm arm64 hppa ia64 m68k ppc ppc64 sparc x86
Arches, please test & mark stable: =dev-libs/openssl-0.9.8z_p1-r1 =dev-libs/openssl-1.0.0m Targets: alpha amd64 arm arm64 hppa ia64 ppc ppc64 sparc x86 Excuse any time wasted. Missed a multilib landmine.
Both stable on alpha.
(In reply to Tony Vroon from comment #24) > Arches, please test & mark stable: > > =dev-libs/openssl-0.9.8z_p1-r1 > =dev-libs/openssl-1.0.0m Most arches should have no need for these at all.
Sorry for the noise, this stuff here will not work as somebody thinks in the ebuild: PLEVEL=`echo ${PV##*_p} | tr [1-26] [a-z]` This works for 1 -> a and 2 -> b, but not the others. It will also do 6 -> c conversion and other anomailies. The dash works for character intervals, not numbers. When we reach _p3, this should be modified to at least to this: PLEVEL=`echo ${PV##*_p} | tr [1-9] [a-i]`
(In reply to Zoltán Halassy from comment #27) > this stuff here will not work + 16 Jun 2014; Tony Vroon <chainsaw@gentoo.org> openssl-0.9.8z_p1-r1.ebuild, + openssl-0.9.8z_p1-r2.ebuild: + I am told my interpretation of the version numbering suggestion will not cope + past 0.9.8ac. Perhaps TR commands should be included on suggestions going + forward. Stabilisation & revision numbering not affected. Trust in user submissions is.
Is awk allowed in ebuilds? If yes, one could write this: PLEVEL=`awk 'BEGIN{ printf "%c", 96+'${PV##*_p}' }'` If not, one could use double printfs (bash builtin): printf -v PLEVEL \\x`printf %x $[${PV##*_p}+96]` If the builtin cannot be used, only the /usr/bin/printf compatible one, one could write this: PLEVEL=`printf \\\x\`printf %x $[${PV##*_p}+96]\``
I don't think my question in comment #26 was addressed. Most architectures don't do old-style multilib and have no need for -0.9.* going stable. 1.0.0m doesn't seem useful there either as 1.0.1h-r1 is going stable in the same SLOT.
(In reply to Jeroen Roovers from comment #30) > I don't think my question in comment #26 was addressed. Most architectures > don't do old-style multilib and have no need for -0.9.* going stable. 1.0.0m > doesn't seem useful there either as 1.0.1h-r1 is going stable in the same > SLOT. So drop off any arches you feel do not belong.
amd64 stable
ia64 stable
ppc stable
ppc64 stable
sparc stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Thanks. We already have a GLSA draft for this.
This issue was resolved and addressed in GLSA 201407-05 at http://security.gentoo.org/glsa/glsa-201407-05.xml by GLSA coordinator Tobias Heinlein (keytoaster).
