|Summary:||<dev-libs/openssl-1.0.1g: Missing bounds check in TLS heartbeat extension (CVE-2014-0160)|
|Product:||Gentoo Security||Reporter:||Kristian Fiskerstrand <k_f>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Severity:||normal||CC:||alexander, alex_y_xu, andrzej.pauli, base-system, boss.gentoo, bug, david.chanial, dennis, djc, flyser42, ftobin, gentoo, hauschild.markus, johan.ymerson, kfm, klausman, klondike, leho, me, mikachu, pchrist, rajiv, randy, redneb, spiderx, thatslyude, tobias.pal, ulm|
|Package list:||Runtime testing required:||---|
Description Kristian Fiskerstrand 2014-04-07 18:49:46 UTC
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)
Comment 1 Mikle Kolyada 2014-04-07 19:30:06 UTC
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"
Comment 2 Kristian Fiskerstrand 2014-04-07 20:31:50 UTC
For those interested in a bit more info on this vulnerability; a Q&A is up at http://heartbleed.com
Comment 3 Alex Xu (Hello71) 2014-04-07 20:59:36 UTC
dev-libs/openssl-1.0.2_beta1 should probably be hardmasked since beta2 isn't out yet to be bumped to.
Comment 4 Samuli Suominen 2014-04-07 21:13:45 UTC
(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
Comment 5 Jeroen Roovers 2014-04-08 01:37:12 UTC
Stable for HPPA.
Comment 6 Chris Reffett 2014-04-08 04:38:25 UTC
*** Bug 507100 has been marked as a duplicate of this bug. ***
Comment 7 Dirkjan Ochtman 2014-04-08 07:02:35 UTC
It's been almost 12h since the call for stable testing. Can we just go with this already?
Comment 8 Matthew Thode ( prometheanfire ) 2014-04-08 07:18:21 UTC
If it helps I'm running it on amd64 on a few servers now.
Comment 9 Dirkjan Ochtman 2014-04-08 07:22:33 UTC
Should there perhaps also be an elog message recommending a restart of relevant services (such as sshd and any httpd you might run)?
Comment 10 Kristian Fiskerstrand 2014-04-08 07:25:27 UTC
As this is TLS specific, sshd shouldn't be affected, however any VPN, IM/XMPP etc would be in addition to httpd services
Comment 11 Samuli Suominen 2014-04-08 07:31:45 UTC
(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.
Comment 12 Leho Kraav (:macmaN @lkraav) 2014-04-08 07:48:07 UTC
What about Prefix? Just synced, 1.0.1f is still the last version available.
Comment 13 Mikle Kolyada 2014-04-08 08:27:23 UTC
(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.
Comment 14 Tobias Klausmann 2014-04-08 08:37:40 UTC
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.
Comment 15 Tobias Klausmann 2014-04-08 08:41:39 UTC
Stable on alpha.
Comment 16 Marcin Mirosław 2014-04-08 08:46:10 UTC
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:)
Comment 17 Vladimir Smirnov (RETIRED) 2014-04-08 08:58:32 UTC
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.
Comment 18 Sergey Popov 2014-04-08 08:59:11 UTC
Comment 19 Kerin Millar 2014-04-08 09:04:25 UTC
(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.
Comment 20 Alex Legler (RETIRED) 2014-04-08 09:06:48 UTC
(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.
Comment 21 Michael Mair-Keimberger (iamnr3) 2014-04-08 09:09:41 UTC
BTW, bugs.gentoo.org  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??  http://filippo.io/Heartbleed/#bugs.gentoo.org
Comment 22 Mikle Kolyada 2014-04-08 09:15:25 UTC
Comment 23 Mikle Kolyada 2014-04-08 09:28:51 UTC
Comment 24 Agostino Sarubbo 2014-04-08 09:36:39 UTC
Comment 25 Agostino Sarubbo 2014-04-08 09:36:46 UTC
ppc64 stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
Comment 26 Mikle Kolyada 2014-04-08 09:50:42 UTC
Cleanup done by Samuli. glsa request filed.
Comment 27 GLSAMaker/CVETool Bot 2014-04-08 10:01:31 UTC
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.
Comment 28 GLSAMaker/CVETool Bot 2014-04-08 10:33:55 UTC
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).
Comment 29 Rajiv Aaron Manglani (RETIRED) 2014-04-08 12:56:57 UTC
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.
Comment 30 Alex Legler (RETIRED) 2014-04-08 12:58:39 UTC
(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.
Comment 31 Peter Volkov (RETIRED) 2014-04-08 13:11:21 UTC
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.
Comment 32 Alex Legler (RETIRED) 2014-04-08 13:13:21 UTC
(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.
Comment 33 Rajiv Aaron Manglani (RETIRED) 2014-04-08 17:55:24 UTC
(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
Comment 34 Francisco Blas Izquierdo Riera 2014-04-08 18:48:57 UTC
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.
Comment 35 Mike Gilbert 2014-04-09 02:38:10 UTC
*** Bug 507190 has been marked as a duplicate of this bug. ***
Comment 36 Mikael Magnusson 2014-04-09 16:27:48 UTC
What about the emul baselibs version?
Comment 37 Alex Legler (RETIRED) 2014-04-10 07:51:05 UTC
(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.
Comment 38 Ulrich Müller 2014-04-11 08:45:21 UTC
(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?