Bug 1084875 (CVE-2014-0160, Heartbleed)
Summary: | CVE-2014-0160 openssl: information disclosure in handling of TLS heartbeat extension packets | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Other] Security Response | Reporter: | Huzaifa S. Sidhpurwala <huzaifas> | ||||||||
Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | |||||||||
Severity: | high | Docs Contact: | |||||||||
Priority: | high | ||||||||||
Version: | unspecified | CC: | aavati, abaron, acathrow, ajz, alex.gaynor, andersk, andresp, aneelica, anil.saldhana, aortega, apevec, ayoung, bazulay, bleanhar, bstinson, btotty, bulk, carnil, ccoleman, cdewolf, chrisw, cpelland, cra, dallan, dev, djorm, dmcphers, dowdle, erik-fedora, fdeutsch, fnasser, forrestt, ggruner, gholms, gkotton, gmollett, hajek, hany, herrold, hkario, hk, huwang, huzaifas, idith, iheim, ispcolohost, jamesaharrisonuk, janfrode, javier.wilson, jawilson, jdetiber, jialiu, jkeck, jkurik, jorti, jrusnack, jwright, kseifried, ksrot, ktietz, lfarkas, lgao, lhh, lmeyer, louiz, manuel.wolfshant, markmc, mattdm, michele, mkosek, mmaslano, mrunge, myarboro, netllama, nick, nlevinki, nonamedotc, paulds, pcheung, pfrields, pgier, pmatouse, pneedle, pslavice, pspacek, pvn, raina, rbryant, redhat-bugzilla, relrod, rfortier, rhos-maint, rhs-bugs, rjones, r.resch, rsvoboda, rvandolson, ry, sclewis, security-response-team, sgallagh, ssaha, stephenf, tchollingsworth, thrcka, tkramer, tmraz, vbellur, vraman, vtunka, weli, yeylon | ||||||||
Target Milestone: | --- | Keywords: | Security | ||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | openssl 1.0.1g | Doc Type: | Bug Fix | ||||||||
Doc Text: |
An information disclosure flaw was found in the way OpenSSL handled TLS and DTLS Heartbeat Extension packets. A malicious TLS or DTLS client or server could send a specially crafted TLS or DTLS Heartbeat packet to disclose a limited portion of memory per request from a connected client or server. Note that the disclosed portions of memory could potentially include sensitive information such as private keys.
|
Story Points: | --- | ||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2014-05-02 16:55:26 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | 1084878, 1084879, 1085065, 1085066, 1085085, 1085088, 1085098, 1085123, 1085161, 1085822, 1086184 | ||||||||||
Bug Blocks: | 1084877 | ||||||||||
Attachments: |
|
Description
Huzaifa S. Sidhpurwala
2014-04-07 05:56:04 UTC
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 |