From $URL: TLS extension parsing race condition. ===================================== A flaw has been found in the OpenSSL TLS server extension code parsing which on affected servers can be exploited in a buffer overrun attack. The OpenSSL security team would like to thank Rob Hulswit for reporting this issue. The fix was developed by Dr Stephen Henson of the OpenSSL core team. This vulnerability is tracked as CVE-2010-3864 Who is affected? ================= All versions of OpenSSL supporting TLS extensions contain this vulnerability including OpenSSL 0.9.8f through 0.9.8o, 1.0.0, 1.0.0a releases. Any OpenSSL based TLS server is vulnerable if it is multi-threaded and uses OpenSSL's internal caching mechanism. Servers that are multi-process and/or disable internal session caching are NOT affected. In particular the Apache HTTP server (which never uses OpenSSL internal caching) and Stunnel (which includes its own workaround) are NOT affected. Recommendations for users of OpenSSL ===================================== Users of all OpenSSL 0.9.8 releases from 0.9.8f through 0.9.8o should update to the OpenSSL 0.9.8p release which contains a patch to correct this issue. Users of OpenSSL 1.0.0 and 1.0.0a should update to the OpenSSL 1.0.0b release which contains a patch to correct this issue. If upgrading is not immediately possible, the relevant source code patch provided in this advisory should be applied.
1.0.0b as in the tree now has the issue that slipped out and caught by the test cases. See the thread at https://groups.google.com/group/mailing.openssl.users/browse_thread/thread/f823f3163070e7d5# There is a patch available.
Created attachment 254619 [details] Build log Shorten the time. I guess this will become a stablereq, so I already leave my feedback. Openssl-1.0.0b fails test, but it runs ( amd64 ) Openssl-1.0.0b fails test, but it runs ( x86 ) Openssl-0.9.8p ok ( amd64 )
What's the point of stating "tests fail" and then attaching a log without any test result at all? Beside the fact that Brant already reported that upstream knows about the failure and we need a -r1?
1.0.0b-r1 is in tree with the upstream patch, thanks Brant. All tests pass now.
Thanks, Diego. Arches, please test and mark stable: =dev-libs/openssl-0.9.8p Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86" =dev-libs/openssl-1.0.0b-r1 Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86"
(In reply to comment #5) > Arches, please test and mark stable: > =dev-libs/openssl-0.9.8p > Target keywords : "alpha amd64 arm hppa ia64 m68k ppc ppc64 s390 sh sparc x86" Do note that SLOT="0.9.8" is only for binary programs, and only amd64 and x86 has such dependencies in tree. Others may wish to skip SLOT="0.9.8" and only get SLOT="0" to avoid unnecessary testing.
(In reply to comment #3) > What's the point of stating "tests fail" and then attaching a log without any > test result at all? Beside the fact that Brant already reported that upstream > knows about the failure and we need a -r1? > sorry, I have attached a log wrong, and I did not realize the message of Brant. Quiet, nothing happened ;) Anyway: =dev-libs/openssl-1.0.0b-r1 ok on amd64. =dev-libs/openssl-0.9.8p ok ( already tested previously )
Stable for HPPA PPC.
x86 done, thanks.
amd64 done. Thanks Agostino
arm stable
alpha/ia64/m68k/s390/sh/sparc stable
ppc64 done
Thanks, everyone. GLSA with bug 332027.
CVE-2010-3864 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2010-3864): Multiple race conditions in ssl/t1_lib.c in OpenSSL 0.9.8f through 0.9.8o, 1.0.0, and 1.0.0a, when multi-threading and internal caching are enabled on a TLS server, might allow remote attackers to execute arbitrary code via client data that triggers a heap-based buffer overflow, related to (1) the TLS server name extension and (2) elliptic curve cryptography.
This issue was resolved and addressed in 201110-01 at http://security.gentoo.org/glsa/glsa-201110-01.xml by GLSA coordinator Tobias Heinlein (keytoaster).