Heartbleed：如何可靠且可移植地检查OpenSSL版本？

我一直在寻找一种可靠且可移植的方法来检查GNU / Linux和其他系统上的OpenSSL版本，因此用户可以轻松地发现由于Heartbleed错误而应该升级自己的SSL。

我以为这很容易，但是我很快在Ubuntu 12.04 LTS上遇到了最新的OpenSSL 1.0.1g问题：

openssl版本-a

我原本希望看到完整版本，但我得到了：

OpenSSL 1.0.1 2012年3月14日
建立于：2013年6月4日星期二07:26:06
平台：[...]

令我不愉快的是，没有显示版本字母。没有f，没有g，只有“ 1.0.1”就这样。列出的日期也无助于发现（非）漏洞版本。

1.0.1（af）和1.0.1g之间的差异至关重要。

问题：

• 检查版本（最好是跨发行版）的可靠方法是什么？
• 为什么没有显示版本号？除了Ubuntu 12.04 LTS之外，我无法在其他任何产品上进行测试。

其他人也报告了此行为。一些例子：

• https://twitter.com/orblivion/status/453323034955223040
• https://twitter.com/axiomsofchoice/status/453309436816535554

一些（特定于发行版的）建议在其中推出：

• Ubuntu和Debian：apt-cache policy openssl和apt-cache policy libssl1.0.0。在此处将版本号与软件包进行比较：http : //www.ubuntu.com/usn/usn-2165-1/
• Fedora 20 ：（yum info openssl感谢@znmeb在Twitter上）和yum info openssl-libs

检查旧版本的OpenSSL是否仍然存在：

• 它并不完全可靠，但是您可以尝试lsof -n | grep ssl | grep DEL。请参阅Heartbleed：如何可靠且可移植地检查OpenSSL版本？为什么这可能对您不起作用。

事实证明，在Ubuntu和Debian上更新OpenSSL软件包并不总是足够的。您还应该更新libssl1.0.0软件包，然后-then-检查是否openssl version -a指示built on: Mon Apr 7 20:33:29 UTC 2014。

基于您的OpenSSL的版本显示的日期，看来你是看到那里显示的完整版本。

Open SSL 1.0.1已于2012年3月14日发布。1.0.1a已于2012年4月19日发布。

因此，我将继续断言这openssl version -a是显示系统上安装的完整版OpenSSL的正确，跨发行版的方式。它似乎适用于我可以访问的所有Linux发行版，也是help.ubuntu.com OpenSSL文档中建议的方法。原始OpenSSL v1.0.1随附了Ubuntu LTS 12.04，这是一个看起来像缩写版本的版本，因为它后面没有字母。

话虽如此，Ubuntu中似乎存在一个重大错误（或它们如何包装OpenSSL）openssl version -a，无论OpenSSL是否已升级到任何版本，该错误都将继续从2012年3月14日开始返回原始1.0.1版本。较新的版本。而且，就像大多数下雨时一样，它会倾泻。

Ubuntu不是唯一将更新反向移植到OpenSSL（或其他软件包）的习惯的主要发行版，它比依赖于每个人都认可的上游更新和版本编号更为重要。在OpenSSL的情况下，字母版本号仅表示错误修复和安全更新，这似乎难以理解，但是我被告知，这可能是由于与OpenSSL一起打包的，经过FIPS验证的主要Linux发行版。由于围绕重新验证的要求会因任何更改而触发，即使这些更改会塞住安全漏洞，因此它是版本锁定的。

例如，在Debian上，固定版本显示的版本号，1.0.1e-2+deb7u5而不是的上游版本1.0.1g。

结果，目前，没有可靠，可移植的方法来检查Linux发行版之间的SSL版本，因为它们都使用自己的向后移植的补丁程序和具有不同版本编号方案的更新。您将必须为运行的每个Linux发行版查找固定的版本号，并对照该发行版的特定版本号检查已安装的OpenSSL版本，以确定您的服务器是否正在运行易受攻击的版本。

如果您想要真正跨平台的产品，请检查漏洞本身，而不要依赖版本号。

您可能具有报告已知易受攻击的版本号的代码，但实际代码并不易受攻击。而相反的-安静易受攻击的代码-可能更糟！

许多捆绑了OpenSSL和OpenSSH之类的开源产品的供应商将选择性地对较旧版本的代码进行紧急修复，以保持API的稳定性和可预测性。对于“长期发布”和设备平台尤其如此。

但是，默默地执行此操作（未添加自己的版本字符串后缀）的供应商冒着在漏洞扫描程序中触发误报的风险（并使用户困惑）。因此，为了使其透明和可验证，一些供应商在主要软件包版本中附加了自己的字符串。Debian（OpenSSL）和FreeBSD（在OpenSSH中，通过VersionAddendumsshd_config指令）有时都可以执行此操作。

不这样做的供应商可能会这样做，以最大程度地减少由于其他程序检查版本号而采用的许多直接和间接方式造成的破坏机会。

所以它看起来像这样：

$ cat /etc/lsb-release 
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.04
DISTRIB_CODENAME=precise
DISTRIB_DESCRIPTION="Ubuntu 12.04.4 LTS"

$ openssl version
OpenSSL 1.0.1 14 Mar 2012

...即使已被修补：

$ dpkg -l openssl | grep openssl
ii  openssl  1.0.1-4ubuntu5.12  [truncated]

$ ls -la `which openssl`
-rwxr-xr-x 1 root root 513208 Apr  7 12:37 /usr/bin/openssl

$ md5sum /usr/bin/openssl
ea2a858ab594905beb8088c7c2b84748  /usr/bin/openssl

有了这样的事情，如果您不信任版本号，您会更好。

不幸的是，我不知道有是这样的一个跨平台的方式。正如我在博客文章中讨论的那样，升级到固定版本后，在Ubuntu 12.04 REMAINS 1.0.1上显示的OpenSSL版本。

仅对于Ubuntu 12.04，如果满足以下所有条件，则可以确定是否已更新：

1. dpkg -s openssl | grep Version 显示版本1.0.1-4ubuntu5.12或更高版本。
2. dpkg -s libssl1.0.0 | grep Version 显示版本1.0.1-4ubuntu5.12或更高版本。
3. openssl version -a 显示2014年4月7日或之后的“构建日期”。

感谢@danny提供其他信息。

请尝试以下方法。它将从ssh链接到的加密库中提取所有字符串。它产生多于一行的输出，但如有必要，可以将其转换为1行。

ldd `which ssh` | awk '/\// { print $3 }' | grep crypto | xargs strings  | grep OpenSSL

产生

OpenSSLDie
DSA_OpenSSL
...
MD4 part of OpenSSL 1.0.1f 6 Jan 2014 
MD5 part of OpenSSL 1.0.1f 6 Jan 2014
... 
etc

例如出现之前在Gentoo上

[ebuild     U  ] dev-libs/openssl-1.0.1f [1.0.1c] USE="bindist (sse2) tls-heartbeat%* zlib -gmp -kerberos -rfc3779 -static-libs {-test} -vanilla" 4,404 kB

上面的命令导致

...
OpenSSL 1.0.1c 10 May 2012

后

...
OpenSSL 1.0.1f 6 Jan 2014

哎呀，还是没有。

这些脚本中的任何一个是否测试所有服务，还是仅测试HTTPS？AFAIK，PostgreSQL容易受到攻击，但这只是谣言，直到狂野的攻击浮出水面。

有一个metasploit脚本可供使用。

https://github.com/rapid7/metasploit-framework/commit/dd69a9e5dd321915e07d8e3dc8fe60d3c54f551a

您可以输入此代码（已通过GnuWin32 OpenSSL二进制版本1.0.1.6 测试，日期为2014-01-14），或仅使用此脚本下方的注释中的脚本。更准确，更简单！

s_client -connect a23-75-248-141.deploy.static.akamaitechnologies.com:443 -debug -state

一旦连接了B型，您将在易受攻击的主机上看到，并且不会断开连接：

B

HEARTBEATING
write to 0x801c17160 [0x801cbc003] (66 bytes => 66 (0x42))
0000 - 18 03 03 00 3d 8f 6f 3c-52 11 83 20 9c a2 c0 49   ....=.o 5 (0x5))
0000 - 18 03 03 00 3d                                    ....=
read from 0x801c17160 [0x801cb7008] (61 bytes => 61 (0x3D))
0000 - 05 4d f5 c0 db 96 d1 f5-c7 07 e5 17 1f 3b 48 34   .M...........;H4
0010 - 6e 11 9d ba 10 0c 3a 34-eb 7b a5 7c c4 b6 c0 c0   n.....:4.{.|....
0020 - b0 75 0e fe b7 fa 9e 04-e9 4e 4a 7d 51 d3 11 1f   .u.......NJ}Q...
0030 - e2 23 16 77 cb a6 e1 8e-77 84 2b f8 7f            .#.w....w.+..
read R BLOCK

您将获得与该响应类似的心跳响应。

在已打补丁的主机上，您将看到类似于以下的响应，并且将断开连接：

输入B

HEARTBEATING
write to 0x801818160 [0x8019d5803] (101 bytes => 101 (0x65))
0000 - 18 03 03 00 60 9c a3 1e-fc 3b 3f 1f 0e 3a fe 4c   ....`....;?..:.L
0010 - a9 33 08 cc 3d 43 54 75-44 7d 2c 7b f3 47 b9 56   .3..=CTuD},{.G.V
0020 - 89 37 c1 43 1c 80 7b 87-66 ff cb 55 5f 8d 1a 95   .7.C..{.f..U_...
0030 - 1b 4c 65 14 21 a1 95 ac-7a 70 79 fc cc a0 cf 51   .Le.!...zpy....Q
0040 - 0f 7e c5 56 14 c8 37 c1-40 0b b8 cb 43 96 8a e6   .~.V..7.@...C...
0050 - 21 42 64 58 62 15 fb 51-82 e6 7f ef 21 1b 6f 87   !BdXb..Q....!.o.
0060 - b9 c2 04 c8 47                                    ....G

资源：

• 博客文章如何测试您的OpenSSL是否流血

还有以下工具：

• https://github.com/titanous/heartbleeder

• http://filippo.io/Heartbleed/

• https://github.com/musalbas/heartbleed-masstest

对于Ubuntu，您可以使用：

aptitude show libssl1.0.0 | grep Version

并与http://www.ubuntu.com/usn/usn-2165-1/进行比较。重新启动（!!!）后，您可以使用进行检查http://possible.lv/tools/hb。

您最好升级到最新的OpenSSL OpenSSL 1.0.1j。

http://blog.vincosolution.com/2014/10/upgrade-openssl-1-0-1j-debianubuntu.html

我在devcentral中找到了这个脚本：

openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe

替换example.com为要检查的服务器的名称或IP地址。

"safe"如果您的服务器正常，"server extension "heartbeat" (id=15)"则返回。

这不依赖于版本号，而是列出导致问题的服务器扩展名，因此它应该不受库版本欺骗的影响。

您正在运行的机器openssl s_client上必须是使用OpenSSL 1.0.1或更高版本，为了这个工作。