A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64kB of memory to a connected client or server. This issue did not affect versions of OpenSSL prior to 1.0.1. Reported by Neel Mehta. Fixed in OpenSSL 1.0.1g (Affected 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1)
Arches, please test and mark stable: =dev-libs/openssl-1.0.1g target KEYWORDS="alpha amd64 arm arm64 hppa ia64 m68k ppc ppc64 sparc x86"
For those interested in a bit more info on this vulnerability; a Q&A is up at http://heartbleed.com
dev-libs/openssl-1.0.2_beta1 should probably be hardmasked since beta2 isn't out yet to be bumped to.
(In reply to Alex Xu (Hello71) from comment #3) > dev-libs/openssl-1.0.2_beta1 should probably be hardmasked since beta2 isn't > out yet to be bumped to. It already is, masked by missing KEYWORDS
Stable for HPPA.
*** Bug 507100 has been marked as a duplicate of this bug. ***
It's been almost 12h since the call for stable testing. Can we just go with this already?
If it helps I'm running it on amd64 on a few servers now.
Should there perhaps also be an elog message recommending a restart of relevant services (such as sshd and any httpd you might run)?
As this is TLS specific, sshd shouldn't be affected, however any VPN, IM/XMPP etc would be in addition to httpd services
(In reply to Matthew Thode ( prometheanfire ) from comment #8) > If it helps I'm running it on amd64 on a few servers now. Yes, it does. While I'm not in the arch team, I have tested on ~amd64 (desktop) and stable x86 (server) too. Marked stable for amd64 and x86.
What about Prefix? Just synced, 1.0.1f is still the last version available.
(In reply to Leho Kraav (:macmaN @lkraav) from comment #12) > What about Prefix? Just synced, 1.0.1f is still the last version available. we does not stabilize for prefix, It is other issue, please open separate bug.
If we add a message to the ebuild regarding restarting binaries, I recommend we mention app-admin/lib_users. In the spirit of full disclosure, I'm the author of lib_users.
Stable on alpha.
Dear maintainers, I'd like to ask you for adding as low as possible +foo USE flags. If someone need tls-heartbeat then will add proper USE flag. I know it's hard to predict which extension/library will have security problem so less USE +flags, less linked libraries = less probability of security hole. Thanks. P.S. It could be nice to have glsa filled earlier than later:)
There is also another CVE fixed in 1.0.1g, CVE-2014-0076: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0076 p.s. I'm also agree with Marcin Mirosław, that tls-heartbeat use flag is ok, but maybe it should be disabled by default.
arm stable
(In reply to Tobias Klausmann from comment #14) > If we add a message to the ebuild regarding restarting binaries, I recommend > we mention app-admin/lib_users. Good idea. I suspect that awareness of this immensely useful tool is limited.
(In reply to Vladimir Smirnov from comment #17) > There is also another CVE fixed in 1.0.1g, CVE-2014-0076: > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-0076 Handled in bug 505278 > > p.s. I'm also agree with Marcin Mirosław, that tls-heartbeat use flag is ok, > but maybe it should be disabled by default. This is not the place to discuss this. Please keep your comments related to the issue at hand. File new bugs for everything else. Thanks.
BTW, bugs.gentoo.org [1] seems to be affected too. Don't know if we need a separate bug here, but it should be updated as soon as possible. Maybe even change the ssl certs?? [1] http://filippo.io/Heartbleed/#bugs.gentoo.org
sparc stable
ia64 stable
ppc stable
ppc64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Cleanup done by Samuli. glsa request filed.
CVE-2014-0160 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-0160): The (1) TLS and (2) DTLS implementations in OpenSSL 1.0.1 before 1.0.1g do not properly handle Heartbeart Extension packets, which allows remote attackers to obtain sensitive information from process memory via crafted packets that trigger a buffer over-read, as demonstrated by reading private keys, related to d1_both.c and t1_lib.c.
This issue was resolved and addressed in GLSA 201404-07 at http://security.gentoo.org/glsa/glsa-201404-07.xml by GLSA coordinator Mikle Kolyada (Zlogene).
openssl 0.9.8y and 1.0.0j (in the portage tree) are not vulnerable, but the list in the GLSA indicates that they are.
(In reply to Rajiv Aaron Manglani from comment #29) > openssl 0.9.8y and 1.0.0j (in the portage tree) are not vulnerable, but the > list in the GLSA indicates that they are. Note the advisory covers two issues.
According to http://filippo.io/Heartbleed/ dev-libs/openssl-1.0.1f is still vulnerable. Looks like we need to stabilize dev-libs/openssl-1.0.1g that is safe according to the same site.
(In reply to Peter Volkov from comment #31) > According to http://filippo.io/Heartbleed/ dev-libs/openssl-1.0.1f is still > vulnerable. Looks like we need to stabilize dev-libs/openssl-1.0.1g that is > safe according to the same site. And we did that as per the stabilization, and the summary, and the GLSA.
(In reply to Alex Legler from comment #30) > (In reply to Rajiv Aaron Manglani from comment #29) > > openssl 0.9.8y and 1.0.0j (in the portage tree) are not vulnerable, but the > > list in the GLSA indicates that they are. > Note the advisory covers two issues. okay about the 1.0.0 branch. however 0.9.8y is not listed as being vulnerable to either issue in the GLSA. https://www.openssl.org/news/vulnerabilities.html
Just for the record the following script allows seeing which services need to be restarted after the upgrade: $ egrep -l 'libssl\.so.* \(deleted\)$' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u Maybe we want to add that to the GLSA.
*** Bug 507190 has been marked as a duplicate of this bug. ***
What about the emul baselibs version?
(In reply to Rajiv Aaron Manglani from comment #33) > (In reply to Alex Legler from comment #30) > > (In reply to Rajiv Aaron Manglani from comment #29) > > > openssl 0.9.8y and 1.0.0j (in the portage tree) are not vulnerable, but the > > > list in the GLSA indicates that they are. > > Note the advisory covers two issues. > > okay about the 1.0.0 branch. however 0.9.8y is not listed as being > vulnerable to either issue in the GLSA. > https://www.openssl.org/news/vulnerabilities.html 0.9 exception in CVS.
(In reply to Mikael Magnusson from comment #36) > What about the emul baselibs version? emul-linux-x86-baselibs-20121202: openssl-1.0.0j emul-linux-x86-baselibs-20130224: openssl-1.0.1c emul-linux-x86-baselibs-20131008: openssl-1.0.1e emul-linux-x86-baselibs-20140406: openssl-1.0.1f Reopen, of should a new bug be filed?
