A missing bounds check was found in the way OpenSSL handled TLS heartbeart extension packets. This flaw could be used to reveal up to 64k of memory from a connected client or server. Only 1.0.1 releases of OpenSSL are affected including 1.0.1f (and 1.0.2 betas) The following upstream commit introduced TLS/DTLS heatbeat support and also this issue: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=4817504
Acknowledgements: Red Hat would like to thank the OpenSSL project for reporting this issue. Upstream acknowledges Neel Mehta of Google Security as the original reporter.
Created attachment 883475 [details] OpenSSL patch
External References: http://www.openssl.org/news/secadv_20140407.txt
Statement: This issue did not affect the versions of openssl as shipped with Red Hat Enterprise Linux 5, Red Hat Enterprise Linux 6.4 and earlier, Red Hat JBoss Enterprise Application Platform 5 and 6, and Red Hat JBoss Web Server 1 and 2. This issue does affect Red Hat Enterprise Linux 7 Beta, Red Hat Enterprise Linux 6.5, Red Hat Enterprise Virtualization Hypervisor 6.5, and Red Hat Storage 2.1, which provided openssl 1.0.1e. Errata have been released to correct this issue. Additional information can be found in the Red Hat Knowledgebase article: https://access.redhat.com/site/announcements/781953
Created openssl tracking bugs for this issue: Affects: fedora-all [bug 1085065]
Created mingw-openssl tracking bugs for this issue: Affects: fedora-all [bug 1085066]
Fixed upstream in OpenSSL version 1.0.1g. Upstream commit: http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db902
This issue was independently discovered by Codenomicon researchers, who use the name "Heartbleed" for this issue: http://heartbleed.com/
Created attachment 883772 [details] 1.0.1e .spec patch to add -DOPENSSL_NO_HEARTBEATS For users looking for a quick workaround while Fedora sorts out the upstream patch or updates to 1.0.1g (not easy, the fedora patches don't apply cleanly).
Created attachment 883804 [details] Patch that applies to OpenSSL 1.0.1e currently in RHEL6 Contains just whitespace adjustments.
Comment on attachment 883804 [details] Patch that applies to OpenSSL 1.0.1e currently in RHEL6 The patched version have been built in koji, so this is obsolete.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2014:0376 https://rhn.redhat.com/errata/RHSA-2014-0376.html
This issue has been addressed in following products: Red Hat Storage 2.1 Via RHSA-2014:0377 https://rhn.redhat.com/errata/RHSA-2014-0377.html
Red Hat Customer Portal announcement with links to solution articles for affected products: https://access.redhat.com/site/announcements/781953
Fedora announce list post: https://lists.fedoraproject.org/pipermail/announce/2014-April/003205.html
This issue has been addressed in following products: RHEV-H and Agents for RHEL-6 Via RHSA-2014:0378 https://rhn.redhat.com/errata/RHSA-2014-0378.html
Fedora Cloud images are respun, and web site is updated. (Thanks to Dennis for the first, and to heroic effort from web team robyduck and shaiton on the web front.) http://fedoraproject.org/get-fedora#clouds
Updates for openssl packages in Fedora 19 and 20 were pushed to stable repositories: https://admin.fedoraproject.org/updates/FEDORA-2014-4910/openssl-1.0.1e-37.fc19.1 https://admin.fedoraproject.org/updates/FEDORA-2014-4879/openssl-1.0.1e-37.fc20.1 https://lists.fedoraproject.org/pipermail/package-announce/2014-April/131291.html https://lists.fedoraproject.org/pipermail/package-announce/2014-April/131221.html
Upstream Node.js source embed a copy of the OpenSSL library. The nodejs packages shipped in Red Hat Software Collections 1, Red Hat OpenShift Enterprise 1, Fedora, and EPEL do not build and use embedded OpenSSL version and rely on the system version. Newer versions remove OpenSSL source form upstream tarballs to ensure patented code is not included in source RPMS. http://pkgs.fedoraproject.org/cgit/nodejs.git/tree/nodejs-tarball.sh?h=f20 https://bugzilla.redhat.com/show_bug.cgi?id=967736
Hello. Small question. If mod_ssl is compiled with OpenSSL 1.0.1, does it need re-compiling with the updated/patched packages? Many thanks, James Harrison
(In reply to James Harrion from comment #35) > If mod_ssl is compiled with OpenSSL 1.0.1, does it need re-compiling with > the updated/patched packages? No, but you need to restart httpd and all other programs using OpenSSL. Follow the link from comment 25 to Red Hat Customer Portal articles which provide additional tips that may help you with identifying processes that need to be restarted.
(In reply to Vincent Danen from comment #9) > Statement: > > This issue did not affect the versions of openssl as shipped with Red Hat > Enterprise Linux 5, Red Hat Enterprise Linux 6.4 and earlier, Red Hat JBoss > Enterprise Application Platform 5 and 6, and Red Hat JBoss Web Server 1 and > 2. This issue does affect Red Hat Enterprise Linux 6.5, Red Hat Enterprise > Virtualization Hypervisor 6.5, and Red Hat Storage 2.1, which provided > openssl 1.0.1e. Does this imply that a RHEL 6.4 with the latest patches as of 4/1/2014 is not vulnerable or only that an unpatched 6.4 or earlier is not vulnerable?
(In reply to Forrest Tiffany from comment #37) > Does this imply that a RHEL 6.4 with the latest patches as of 4/1/2014 is > not vulnerable or only that an unpatched 6.4 or earlier is not vulnerable? RHEL 6.4 currently has openssl-1.0.0-27.el6_4.2 and is NOT vulnerable. As mentioned earlier in this flaw, only openssl-1.0.1 is vulnerable to this issue.
The openssl packages in Red Hat Enterprise Linux 6 were updated from version 1.0.0 to version 1.0.1 as part of Red Hat Enterprise Linux 6.5 via the following erratum: https://rhn.redhat.com/errata/RHBA-2013-1585.html Support for TLS/DTLS heartbeat was only added upstream in version 1.0.1.
Few references related to this issue: RFC 6520, which defines Heartbeat extension for TLS and DTLS: https://tools.ietf.org/html/rfc6520 CERT advisories: https://www.cert.fi/en/reports/2014/vulnerability788210.html http://www.kb.cert.org/vuls/id/720951 http://www.us-cert.gov/ncas/alerts/TA14-098A Media / blog coverage: http://arstechnica.com/security/2014/04/critical-crypto-bug-in-openssl-opens-two-thirds-of-the-web-to-eavesdropping/ https://lwn.net/Articles/593809/ https://www.schneier.com/blog/archives/2014/04/heartbleed.html Good explanation from Matthew Green, covering issue and impact: http://blog.cryptographyengineering.com/2014/04/attack-of-week-openssl-heartbleed.html CloudFlare blog post that cause lot of controversy: https://blog.cloudflare.com/staying-ahead-of-openssl-vulnerabilities Another explanation of the issue details, including limits of the leak: http://blog.existentialize.com/diagnosis-of-the-openssl-heartbleed-bug.html While Codenomicon researchers report easily verifiable leak of private keys, other researchers, including the reporter of the issue, report lack or partial success leaking private key data: https://twitter.com/neelmehta/statuses/453625474879471616 https://twitter.com/agl__/status/453370767690829825 https://twitter.com/agelastic/status/453467109217955840 However, there are multiple reports of successful leaks of other sensitive data from public web sites affected by this issue, including leaks of session cookies and authentication credentials: http://arstechnica.com/security/2014/04/critical-crypto-bug-exposes-yahoo-mail-passwords-russian-roulette-style/ https://www.mattslifebytes.com/?p=533 In addition to various online tools that can be used to check public servers for this issue, there are multiple tools/scripts available that check for the issue, including modules in scanning / security tools as nmap or metasploit: https://github.com/musalbas/heartbleed-masstest/blob/master/ssltest.py https://github.com/FiloSottile/Heartbleed https://github.com/Lekensteyn/pacemaker http://nmap.org/nsedoc/scripts/ssl-heartbleed.html https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse https://community.rapid7.com/community/metasploit/blog/2014/04/09/metasploits-heartbleed-scanner-module-cve-2014-0160 https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/ssl/openssl_heartbleed.rb https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/server/openssl_heartbeat_client_memory.rb
(In reply to Forrest Tiffany from comment #37) >> Does this imply that a RHEL 6.4 with the latest patches as of 4/1/2014 is >> not vulnerable or only that an unpatched 6.4 or earlier is not vulnerable? > RHEL 6.4 currently has openssl-1.0.0-27.el6_4.2 and is NOT vulnerable. As > mentioned earlier in this flaw, only openssl-1.0.1 is vulnerable to this issue. (In reply to Tomas Hoger from comment #39) > The openssl packages in Red Hat Enterprise Linux 6 were updated from version > 1.0.0 to version 1.0.1 as part of Red Hat Enterprise Linux 6.5 via the > following erratum: > > https://rhn.redhat.com/errata/RHBA-2013-1585.html > > Support for TLS/DTLS heartbeat was only added upstream in version 1.0.1. These two statements are contradictory. Do the updates to RHEL 6 not get installed if I used RHEL 6.4 as my install media vs later using RHEL 6.5 as my install media? I understand that the OpenSSL that was on the install media for 6.4 is NOT vulnerable and that the OpenSSL that is on the install media for 6.5 IS vulnerable. But, once a 6.4 is patched does it not get ALL of the RHEL 6 updates? According to the link provided: "Updated openssl packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6." and the packages listed (I'm only including the SRPM for brevity): "openssl-1.0.1e-15.el6.src.rpm File outdated by: RHSA-2014:0376"
If you installed 6.4 and then ran updates to update it to 6.5, then you were running 6.5, and OpenSSL 1.0.1, from that point forward. I'm not sure why you are finding this so difficult to understand. Check your /var/log/yum.log* files to find exactly when you installed the updates that took you to 6.5 if you don't remember doing it.
(In reply to Shabba from comment #44) > If you installed 6.4 and then ran updates to update it to 6.5, then you were > running 6.5, and OpenSSL 1.0.1, from that point forward. I'm not sure why > you are finding this so difficult to understand. Check your > /var/log/yum.log* files to find exactly when you installed the updates that > took you to 6.5 if you don't remember doing it. I'm NOT finding it difficult to understand. I just want it to be made clear whether or not installing RHEL 6 via RHEL 6.4 install media and then doing the typical "yum update" leaves you in an invulnerable state. I am also not trying to verify that MY systems are vulnerable as I do not administer any RHEL systems at this time. I am trying to verfy that when someone else tells me they are not vulnerable because they installed RHEL 6.4 that I can trust that statement. The problem is increased if the openssl package is not updated because the normal vefification of a CVE patch (rpm -qa --changelog | grep CVE-YYYY-NNNN) would show them as vulnerable (since it would return nothing) as opposed to patched.
(In reply to Forrest Tiffany from comment #43) > These two statements are contradictory. Do the updates to RHEL 6 not get > installed if I used RHEL 6.4 as my install media vs later using RHEL 6.5 as > my install media? If you installed Red Hat Enterprise Linux 6 from 6.4 media and installed all updates since then, you already installed all updates that were released as part of 6.5 minor release. If you install openssl update RHBA-2013:1585 (or any subsequent openssl update), you updated to affected version regardless of what media you originally installed from. Use 'rpm -q openssl' to see what version you currently have installed. The confusion may be related to the fact that there is a support / update stream for Red Hat Enterprise Linux 6.4 that does not include 6.5 updates. That has openssl-1.0.0-27.el6_4.2 as the latest released version. See section for Extended Update Support on Red Hat Enterprise Linux Life Cycle page for further details: https://access.redhat.com/site/support/policy/updates/errata/#Extended_Update_Support
This issue has been addressed in following products: RHEV-H and Agents for RHEL-6 Via RHSA-2014:0396 https://rhn.redhat.com/errata/RHSA-2014-0396.html
According to the OpenSSL web site the versions of OpenSSL were: Apr 7 19:21:29 2014 openssl-1.0.1g Jan 6 15:39:19 2014 openssl-1.0.1f Feb 11 16:34:23 2013 openssl-1.0.1e Feb 5 13:17:07 2013 openssl-1.0.1d May 10 17:20:24 2012 openssl-1.0.1c Apr 26 12:52:52 2012 openssl-1.0.1b Apr 19 14:20:37 2012 openssl-1.0.1a Mar 14 14:34:38 2012 openssl-1.0.1 Feb 24 00:07:06 2012 openssl-1.0.1-beta3 Jan 19 17:50:55 2012 openssl-1.0.1-beta2 Jan 3 14:41:35 2012 openssl-1.0.1-beta1 Feb 5 13:17:00 2013 openssl-1.0.0k Jan 6 16:04:52 2014 openssl-1.0.0l May 10 17:07:50 2012 openssl-1.0.0j Apr 19 13:55:31 2012 openssl-1.0.0i Mar 12 16:36:25 2012 openssl-1.0.0h Jan 18 14:43:42 2012 openssl-1.0.0g Jan 4 18:18:15 2012 openssl-1.0.0f Sep 6 15:21:26 2011 openssl-1.0.0e Did the bug get introduced from the jump from 1.0.0k to 1.0.1-beta1? Thanks, James Harrison
Affected functionality was introduced upstream in version 1.0.1. We have not investigated 1.0.1-beta versions as those are not shipped by Red Hat. You can use info from comment 0 to check beta versions if you are interested. Comment 9 and comment 39 provide more information on affected Red Hat Enterprise Linux versions.
Updates for mingw-openssl packages in Fedora 19 and 20 were also pushed to stable repositories earlier this week: https://admin.fedoraproject.org/updates/FEDORA-2014-4999/mingw-openssl-1.0.1e-6.fc19 https://admin.fedoraproject.org/updates/FEDORA-2014-4982/mingw-openssl-1.0.1e-6.fc20 https://lists.fedoraproject.org/pipermail/package-announce/2014-April/131532.html https://lists.fedoraproject.org/pipermail/package-announce/2014-April/131346.html
This issue has been addressed in following products: RHEV Manager version 3.3 Via RHSA-2014:0416 https://rhn.redhat.com/errata/RHSA-2014-0416.html