截至今天，已发现OpenSSL中的错误影响到版本1.0.1至1.0.1f（包括1.0.2-beta和1.0.1g）。

自Ubuntu 12.04起，我们都容易受到此错误的影响。为了修补此漏洞，受影响的用户应更新到OpenSSL q4312079q。

每个受影响的用户如何立即应用此更新？

评论

您是否有受影响的openssl版本？
我已经安装了修补程序版本1.0.1-4ubuntu5.12，并且已经重新启动了apache服务，但是我网站上的filippo.io/Heartbleed测试仍然显示我很脆弱。知道为什么吗？
@Mat我不知道该站点要测试什么，但是也许它检测到您正在使用旧密钥。由于密钥可能已泄漏，因此需要重新生成密钥。
您真的不想将OpenSSL更新为批发新版本，这是令人难以置信的痛苦。只需安装用于修补该问题的更新程序包，即可轻松得多：ubuntu.com/usn/usn-2165-1
升级后您是否重新启动了服务？

#1 楼

安全更新适用于12.04、12.10、13.10和14.04，请参阅Ubuntu安全公告USN-2165-1。

因此，首先您需要应用可用的安全更新，例如，通过从命令行运行

sudo apt-get update
sudo apt-get upgrade


。

不要忘记重启使用受影响的OpenSSL版本的服务（HTTP，SMTP等），否则您仍然容易受到攻击。另请参阅Heartbleed：这是什么，有哪些缓解方法？在Serverfault.com上。

以下命令显示（升级后）所有需要重新启动的服务：

sudo find /proc -maxdepth 2 -name maps -exec grep -HE '/libssl\.so.* \(deleted\)' {} \; | cut -d/ -f3 | sort -u | xargs --no-run-if-empty ps uwwp


之后，您需要重新生成所有服务器SSL密钥，然后评估您的密钥是否已泄漏，在这种情况下，攻击者可能已从服务器中检索了机密信息。

评论

不确定这是否适用于Ubuntu 12.04.4 LTS。全面更新后，openssl版本会提供OpenSSL 1.0.1（2012年3月14日）。那不是补丁版本，对吧？还是我看错了？

– Paul Cantrell
2014年4月8日在6:05


与Ubuntu 13.04有什么关系？没有可用的升级版openssl ：-(

– Frodik
2014年4月8日在6:14
在Ubuntu 12.04上，甚至固定的OpenSSL也会显示版本1.0.1（2012年3月14日）。阅读crimi的答案以了解您的安装是否包括此修复程序。

– dan
2014年4月8日在7:34


谢谢，@ dan！在这里重新总结@crimi的答案：如果您运行dpkg -l | grep'openssl'，您会得到1.0.1-4ubuntu5.12，然后就可以了。

– Paul Cantrell
2014年4月8日在8:21
修补和重新启动是不够的。您需要重新生成密钥，并评估您的密钥以及其他机密材料是否已泄漏。参见例如Heartbleed是否为每个SSL服务器都意味着新证书？

–吉尔斯'所以-不再是邪恶的'
2014年4月8日在9:34

#2 楼

该错误称为Heartbleed。

我容易受到攻击吗？

通常，如果您运行某个服务器并在某个时候生成了SSL密钥，则您会受到影响。大多数最终用户没有（直接）受到影响；至少Firefox和Chrome不使用OpenSSL。 SSH不受影响。 Ubuntu软件包的分发不会受到影响（它依赖于GPG签名）。

如果运行任何使用OpenSSL版本1.0–1.0.1f的服务器（当然，自发现错误以来已被修补）。受影响的Ubuntu版本为11.10 oneiric到14.04可信预发行版。这是一个实现错误，而不是协议中的缺陷，因此只有使用OpenSSL库的程序才会受到影响。如果您有一个与旧版OpenSSL 0.9.x版本链接的程序，则不会受到影响。仅使用OpenSSL库实现SSL协议的程序会受到影响；使用OpenSSL进行其他操作的程序不会受到影响。

如果您运行的是暴露于Internet的易受攻击的服务器，除非自2014年4月7日发布以来您的日志未显示任何连接，否则认为它已受到威胁。 （这假定该漏洞在发布之前未被利用。）如果您的服务器仅在内部公开，则是否需要更改密钥取决于其他安全措施。

什么

该错误允许任何可以连接到SSL服务器的客户端从该服务器检索大约64kB的内存。客户端不需要以任何方式进行身份验证。通过重复攻击，客户端可以连续尝试转储内存的不同部分。

攻击者可能能够检索的关键数据之一是服务器的SSL私钥。有了这些数据，攻击者就可以冒充您的服务器。

如何在服务器上进行恢复？


使所有受影响的服务器脱机。只要它们在运行，它们就有可能泄漏关键数据。
升级libssl1.0.0程序包，并确保所有受影响的服务器都重新启动。
您可以检查受影响的进程是否仍在使用` grep'libssl。（deleted）'/ proc // maps`

生成新密钥。这是必需的，因为该错误可能使攻击者获得了旧的私钥。请遵循最初使用的相同步骤。


如果使用由证书颁发机构签名的证书，请将新的公共密钥提交给CA。收到新证书后，将其安装在服务器上。
如果使用自签名证书，则将其安装在服务器上。
两种方法都将旧密钥和证书移开（但不要删除它们，只要确保它们不再被使用就可以了。


现在有了新的安全密钥，您可以使服务器恢复在线。
吊销旧证书。

损坏评估：服务于SSL连接的进程的内存中的任何数据都可能被泄漏。这可以包括用户密码和其他机密数据。您需要评估这些数据可能是什么。


如果您正在运行允许密码认证的服务，那么在漏洞宣布之前不久就已连接的用户的密码应被视为受到损害。 （前一阵子，因为密码可能已经在内存中使用了一段时间。）检查您的日志并更改任何受影响用户的密码。
还要使所有会话cookie无效，因为它们可能已被破坏。
客户端证书不会受到破坏。
自漏洞发生前不久交换的任何数据都可能保留在服务器的内存中，因此可能已泄露给攻击者。
如果有人记录了旧的SSL连接并检索了服务器的密钥，则他们现在可以解密其笔录。 （除非确保了PFS-如果您不知道，那就不是。）



如何在客户端上恢复？

只有少数几种情况会影响客户端应用程序。服务器端的问题是任何人都可以连接到服务器并利用该错误。为了利用客户端，必须满足三个条件：


客户端程序使用错误版本的OpenSSL库来实现SSL协议。
客户端连接到恶意服务器。 （因此，例如，如果您连接到电子邮件提供商，则不必担心。）这必须在服务器所有者意识到此漏洞之后发生，大概是在2014-04-07之后。
客户端进程中的机密数据未与服务器共享。 （因此，如果您只是运行wget来下载文件，则不会泄漏任何数据。）

如果您在2014年4月7日晚上UTC和升级OpenSSL库之间进行了此操作，请考虑

参考文献




Heartbleed Bug（由两个独立发现该错误的团队之一） ）
OpenSSL TLS心跳（Heartbleed）攻击的工作原理是什么？
Heartbleed意味着每个SSL服务器都有新的证书吗？
Heartbleed：它是什么，有什么缓解方法？


评论

我不相信“仅SSL / TLS连接的服务器端受到影响”是真的。 openssl.org/news/secadv_20140407.txt说，它可以揭示来自客户端或服务器的机密。 ubuntu.com/usn/usn-2165-1同意。连接到恶意服务器时使用客户端证书的机会很小，但是这种可能性存在。

– Armb
2014年4月8日在12:14
@armb你说的很对。甚至不使用客户端证书也没关系，数据泄漏与证书的使用无关。我已征求专业人员的帮助。

–吉尔斯'所以-不再是邪恶的'
2014年4月8日在12:58
客户端证书是您泄漏私钥的情况，但是可以，密码，授权cookie等仍然可能泄漏。但是，对于典型使用的基于OpenSSL的客户端（例如curl或wget），在连接到恶意服务器时您不会在内存中拥有其他站点的秘密，因此在那种情况下，我认为唯一的泄漏就是您提供了客户端秘密预期将它们提供给合法站点，并且Heartbleed在握手期间泄漏了它们，然后证书验证显示您没有连接到正确的站点。

– Armb
2014年4月9日在8:41
@Gilles您可能会对“哪些客户被证明容易受到Heartbleed？”的答案感兴趣。我设法在nginx（代理模式），wget，链接等上获得了“有趣的”内存。

– Lekensteyn
2014年4月10日7:50
@MuhamedHuseinbašićopenssl软件包包含命令行工具。使用OpenSSL库来实现SSL协议的应用程序（例如Apache）不使用它。但是您应该只应用发行版的安全更新。

–吉尔斯'所以-不再是邪恶的'
17年7月7日在18:01

#3 楼

要查看在Ubuntu上安装了哪个OpenSSL版本，请运行：

dpkg -l | grep openssl


如果看到以下版本输出，则应包括CVE-2014-0160的补丁。

ii  openssl      1.0.1-4ubuntu5.12      Secure Socket Layer (SSL)...


看看https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12，它显示出已修复的错误类型：

...
 SECURITY UPDATE: memory disclosure in TLS heartbeat extension
    - debian/patches/CVE-2014-0160.patch: use correct lengths in
      ssl/d1_both.c, ssl/t1_lib.c.
    - CVE-2014-0160
 -- Marc Deslauriers <email address hidden>   Mon, 07 Apr 2014 15:45:14 -0400
...


评论

我已经升级并获得了5.12版，但是该工具仍然告诉我我很容易受害filippo.io/Heartbleed Thoughts？

– toxaq
2014年4月8日在11:23
我已经在这边测试了更新的服务器，它告诉我我不受影响。您是否重新启动了系统，或者至少确定所有必需的进程都已重新启动？

–crimi
2014年4月8日在11:33
更新OPENSSL之后，我所要做的就是重新启动apache服务，但是优雅的操作并没有帮助。我不得不去使用sudo service apache2 restart重启

–汤姆·赫特（Tom Hert）
2014年4月8日在17:14
我刚刚发现漏洞的原因：我安装了mod-spdy-beta。删除它并重新启动apache之后，所有测试现在都是绿色的。

–安德烈亚斯·罗斯（Andreas Roth）
2014年4月9日下午5:30
更新openssl不能修复Apache，Nginx或postfix等应用程序。您必须按照其他帖子中的说明更新libssl1.0.0并重新启动它们。

–tnj
2014年4月10日在10:28

#4 楼

如果您的apt-get存储库不包含任何预编译的1.0.1g OpenSSL版本，那么只需从官方网站下载源代码并进行编译即可。

在单个命令行下方即可编译和安装最新的openssl版本。

curl https://www.openssl.org/source/openssl-1.0.1g.tar.gz | tar xz && cd openssl-1.0.1g && sudo ./config && sudo make && sudo make install

通过符号链接将旧的openssl二进制文件替换为新的。

sudo ln -sf /usr/local/ssl/bin/openssl `which openssl`


一切顺利！

# openssl version should return
openssl version
OpenSSL 1.0.1g 7 Apr 2014


此博客文章。

NB：如博客文章中所述，此解决方法无法解决“ Nginx和必须使用1.0.1g openSSL源重新编译的Apache服务器。“

评论

通常，Ubuntu不提供新的上游版本，而是为所有受支持的发行版打补丁，以将更改保持在最低水平。

–弗洛里安·迪切
2014年4月8日在2:55
注意：确保在更新OpenSSL之后重新启动服务器。 Apache和Nginx选择了新库，该漏洞已关闭。

– dAngelov
2014年4月8日在17:27
嘿，现在我花时间阅读这篇文章的详细信息，我感到更加震惊-从Internet的某个随机位置下载一个tarball，解压缩并以root身份执行其中的一部分只是鲁ck的行为。如果下载并检查了tarball签名会更好一些，但是要确保您验证签名是通过正确的密钥签名的，这本身就是一个难题。分发已经致力于确保tarball和补丁的安全来源。谢谢。

– sarnold
2014年4月9日下午0:05
现在最好从源代码进行编译，然后再从apt安装一个新版本，这是个好主意，这样一来，您比以前的ubuntu发行版要安全得多，反而只有两分钱

– nwgat
2014年4月10日下午16:02
@sarnold openssl.org似乎不是一个随意的地方来下载openssl的源代码。 Canonical应该使此操作不必要，但openssl.org应该是工作的权威上游。

–罗斯塔沃尔
16/09/13在15:53

#5 楼

对于那些不想进行服务器级软件包升级的用户。我今天读了一堆这些指南，并且将应用您的计算机所需的所有安全修复程序。除非您明确地在某个地方使用旧版本的软件包，否则它会很棒。

这是在运行Apache 2的Ubuntu 12.04 LTS上所需的最少操作：


转到此地址并证明您有漏洞。您应该使用Web服务器的直接外部地址。如果使用负载均衡器（例如ELB），则可能不会直接与Web服务器联系。

运行以下1个衬板以升级软件包并重新启动。是的，我看到所有指南都说您应该在2014年4月4日之后添加时间戳记，但在我看来情况并非如此。

apt-get更新&& apt-get安装openssl libssl1.0.0 && /etc/init.d/apache2重新启动

确保已安装适当的软件包版本并检查Web服务器再次解决该漏洞。

关键软件包如下，我使用下面的命令确定了这些信息，然后删除了所有内容（您不需要了解我的计算机的状态那么多） ）。 

$ dpkg -l | grep ssl

ii  libssl-dev                       1.0.1-4ubuntu5.12          SSL development libraries, header files and documentation
ii  libssl1.0.0                      1.0.1-4ubuntu5.12          SSL shared libraries
ii  openssl                          1.0.1-4ubuntu5.12          Secure Socket Layer (SSL)* binary and related cryptographic tools


apt-get upgrade openssl不应包含此漏洞。通过再次访问下面的网站并测试您的Web服务器，确保是这种情况。

http://filippo.io/Heartbleed/

评论

对我而言，使用外部站点证明服务器中的漏洞似乎是错误的方法。

–灵风
2014年4月8日在22:00
如今，外部漏洞测试脚本变得越来越普遍。它完全可以执行内部脚本的操作，只是从外部Web服务器启动连接。您可以查看WhiteHatSecurity.com之类的网站，作为远程​​启动所有连接的程序示例。在某些情况下，这是行不通的，例如网络漏洞测试，但是对于测试面向前的Web服务器（通常是SSL服务器），这几乎是理想的。

–阿德里安
2014年4月8日在23:03
如果要升级，为什么要安装该软件包？

–脑袋
2014年4月9日下午0:37
apt-get install openssl libssl1.0.0为我做到了。正在运行openssl版本-a现在显示：构建于：UTC 2014年4月7日星期一20:33:29

–地雷
2014年4月9日在7:26
“如今，外部漏洞测试脚本变得越来越普遍。”这使得外部站点滥用我的系统成为可能：他们需要知道它会失败并在对我的系统进行修补之前对其进行黑客攻击。不，这不是正确的方法。 （是的，我用apache和openssl托管自己的网站）。

–灵风
14-4-10在12:13


#6 楼

我注意到这里有许多评论者迫切需要帮助。他们正在遵循说明，升级，重新引导，并且在使用某些测试网站时仍然容易受到攻击。

您必须检查以确保没有保留的软件包，例如libssl。

:~$ sudo apt-get upgrade -V
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages have been kept back:
  libssl-dev (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  libssl1.0.0 (1.0.1-4ubuntu5.10 => 1.0.1-4ubuntu5.12)
  linux-image-virtual (3.2.0.31.34 => 3.2.0.60.71)
  linux-virtual (3.2.0.31.34 => 3.2.0.60.71)
0 upgraded, 0 newly installed, 0 to remove and 4 not upgraded.


要升级那些apt-mark unhold libssl1.0.0（例如， ）。然后升级：apt-get upgrade -V。然后，重新启动受影响的服务。