题 Heartbleed:如何可靠,便携地检查OpenSSL版本?


我正在寻找一种可靠且可移植的方式来检查GNU / Linux和其他系统上的OpenSSL版本,因此用户可以轻松地发现他们是否应该因为Heartbleed错误而升级他们的SSL。

我觉得这很容易,但我很快就遇到了Ubuntu 12.04 LTS上最新OpenSSL 1.0.1g的问题:

openssl版本-a

我期待看到一个完整版本,但我得到了这个:

OpenSSL 1.0.1 2012年3月14日
建立于:Tue Jun 4 07:26:06 UTC 2013
平台:[...]

令我不愉快的是,版本字母没有显示。没有f,没有g,只有“1.0.1”就是这样。列出的日期也无助于发现(非)易受攻击的版本。

1.0.1(a-f)和1.0.1g之间的差异至关重要。

问题:

  • 什么是检查版本的可靠方法,最好是交叉发行版?
  • 为什么版本字母首先没有显示?除了Ubuntu 12.04 LTS,我无法测试其他任何东西。

其他人也报告了这种行为。几个例子:

一些(发布特定的)建议滚动:

  • 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 (感谢Twitter上的@znmeb)和 yum info openssl-libs

检查旧版本的OpenSSL是否仍然驻留:

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


86
2018-04-07 23:51




至少要确定你拥有的OpenSSL版本 不 g因为它显示的日期 - Pato Sáinz
这适用于CentOS [root@null~]# openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013 - Jacob
@PatoSáinz我查了一下 apt-cache policy openssl 并回复: Installed: 1.0.1-4ubuntu5.12 这是Ubuntu刚刚发布的12.04 LTS 1.0.1g。我退出并重新登录。还有什么我可以做的验证吗? - Martijn
我会指出,对于那些不知道,如果它有用... Ubuntu 12.04 LTS附带OpenSSL 1.0.1(vanilla)。 - HopelessN00b
如果构建日期是准确的,那么你不能拥有比1.0.1e更新的“发布版本”代码,因为1.0.1f是在2014年出现的 OpenSSL 1.0.1发行说明。当然,在正式的OpenSSL 1.0.1f版本发布之前,各个行或部分可能已经被移植到您的Ubuntu版本中。并且构建日期可能不那么完全有用。 - Anti-weakpasswords


答案:


根据您的OpenSSL版本显示的日期,您似乎  看到那里显示的完整版本。

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

所以,我将继续并断言 openssl version -a 是显示系统上安装的完整版OpenSSL的正确,交叉发行方式。它似乎适用于我可以访问的所有Linux发行版,以及 是help.ubuntu.com OpenSSL文档中建议的方法。 Ubuntu LTS 12.04附带vanilla OpenSSL v1.0.1,该版本看起来像一个缩写版本,因为没有跟随它的字母。

话虽如此,似乎有一个 重大的 Ubuntu中的错误(或者它们如何打包OpenSSL) openssl version -a 无论OpenSSL是否已升级到任何较新版本,都将从2012年3月14日起继续返回原始1.0.1版本。而且,和下雨时的大多数事情一样,它倒了。

Ubuntu并不是唯一一个将更新后移到OpenSSL(或其他软件包)的主要发行版,而不是依赖于每个人都认可的上游更新和版本编号。在OpenSSL的情况下,字母版本号仅代表错误修复和安全更新,这似乎几乎不可理解,但我被告知这可能是因为 FIPS认证 与OpenSSL打包在一起的插件主要Linux发行版。由于由于任何更改而触发的重新验证要求,即使插入安全漏洞的更改,它也是版本锁定的。

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

结果,在这个时候, 没有可靠,可移植的方法来检查Linux发行版中的SSL版本,因为他们都使用自己的backported补丁和更新与不同的版本编号方案。您必须查找运行的每个不同Linux发行版的固定版本号,并根据该发行版的特定版本编号检查已安装的OpenSSL版本,以确定您的服务器是否运行易受攻击的版本。


67
2018-04-08 00:05



我的安装是一个简单的Ubuntu 12.04 LTS没有任何我自己编译或从Ubuntu存储库以外的其他来源下载。如果Ubuntu正在分发带有缩写版本号的OpenSSL,那么 openssl version -a 不是一种可移植的方法(至少不能移植到Ubuntu)。我查过了 apt-cache policy openssl 并回复: Installed: 1.0.1-4ubuntu5.12 这是Ubuntu刚刚发布的12.04 LTS 1.0.1g。在检查之前我退出并重新登录。 - Martijn
HopelessN00b,没有任何可疑的反向移植修复政策,而不是碰撞版本;这是确保平台稳定性的一种非常好的方法,这在服务器环境中是非常需要的。像任何决定一样,它有后果,用户需要注意;但只是因为它打破了“我正在运行foo x.y.z因此我/我不容易受到最新漏洞攻击“推理线,这并不是一件坏事。 - MadHatter
@towo版本号存在是有原因的。如果我们只是将上游版本的数字从窗口中删除,因为“企业”,或者其他什么,为什么要打扰版本号呢?也可以开始用头韵来命名我们所有的东西。我们可以调用易受攻击的OpenSSL版本 圣洁的Heartbleed 和固定的 狡猾的混凝剂。 - HopelessN00b
@ HopelessN00b我认为你已经开始关注“这是在X.Y.Z版本中修复的”陷阱,它们不遵循版本号,因为所有导入到最新版本的都是错误和安全修复。如果他们碰到了版本号,你也会期待额外的功能。“我有OpenSSL v X.Y.Z,为什么我没有ECDHA ???? .. iec”。当你明白它只是错误修正时才有意义。 - NickW
@NickW @Jubal @MadHatter与OpenSSL的关系是: After the release of OpenSSL 1.0.0 the versioning scheme changed. Letter releases (e.g. 1.0.1a) can only contain bug and security fixes and no new features. 因此,没有放弃上游版本控制方案;向后移植更新与使用更新版本基本相同,因为更新仅包括安全性和错误修复。它所做的是让事情混乱,让我们无法在Linux发行版中轻松检查OpenSSL版本。 - HopelessN00b


如果你想要一些真正跨平台的东西, 检查漏洞本身而不是依赖版本号。 

您可能拥有报告已知易受攻击的版本号的代码, 但实际的代码并不容易受到攻击。反向 - 无声的易受攻击的代码 - 可能更糟糕!

许多捆绑OpenSSL和OpenSSH等开源产品的供应商会选择性地将旧版本代码的紧急修复程序改装,以保持API的稳定性和可预测性。对于“长期发布”和设备平台尤其如此。

但默默地执行此操作(不添加自己的版本字符串后缀)的供应商可能会在漏洞扫描程序中触发误报(并使用户感到困惑)。因此,为了使其透明且可验证,一些供应商将自己的字符串附加到主要包版本。 Debian(OpenSSL)和FreeBSD(在OpenSSH中,通过 VersionAddendum sshd_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

有了这样的事情,如果你这样做会更好 不信任版本号。


18
2018-04-08 20:52



很明显,检查版本并不像我希望的那样容易和透明。检查漏洞是跨平台的,但也更难做:您必须拥有可靠的PoC或测试方便您正在运行的特定易受攻击的软件服务。在这种情况下,它都是从Apache和nginx的PoC开始的。如果那时我只使用带SSL的SMTP,我想检查一下我是否容易受到攻击?最终我们将对大多数服务进行测试,但可能需要一段时间。 - Martijn
Martijn,这是一个公平的观点。当测试不可用时,辅助方法(如跟踪目标系统上受影响的二进制文件的校验和)不太理想,但可能足以完成工作......然后继续进行下一次攻击。 :-) - Royce Williams


不幸的是,我不确定那里  这是一种跨平台的方式。 正如我在博客中讨论的那样,升级到固定版本后,OpenSSL的版本显示在Ubuntu 12.04 REMAINS 1.0.1上。

仅对于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提供的其他信息。


14
2018-04-08 03:15



好的,在这种情况下,我必须添加该软件包版本 1.0.1-4ubuntu5.12 仅适用于Ubuntu 12.04 LTS。如果您使用的是Ubuntu 12.10,您应该至少看到版本 1.0.1c-3ubuntu2.7 如果你在13.10那么它至少应该是版本 1.0.1e-3ubuntu1.2据消息来源称: ubuntu.com/usn/usn-2165-1 - Martijn
遗憾的是,这是不够的。您 必须 也升级 libssl1.0.0 明确地在ubuntu上。如果您在2014年4月7日之前看到建立日期,即使openssl版本看起来正确(1.0.1-4ubuntu5.12 对于Ubuntu 12.04而言,你可能仍然很脆弱。 - danny
@danny你刚刚救了我很多工作。我试图弄清楚为什么构建日期在某些12.04系统上是正确的而在其他系统上是错误的。你是一个救星! - Schof
openssl version -a 可能不需要4月7日的构建日期,因为修复程序被反向移植到旧版本。 - Patrick James McDougle


试试以下内容。它将从中提取所有字符串 加密 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

哎哟,还是没有。


4
2018-04-08 14:45



我认为你非常接近提供一个很好的解决方案,但不幸的是,这对Ubuntu 12.04 LTS上的加密库不起作用。它显示所有带有版本的字符串 [...] part of OpenSSL 1.0.1 14 Mar 2012,就像 openssl version -a 确实。这是一个可能在其他情况下工作的技巧! - Martijn
@Martijn那很不幸,但它确实适用于ubuntu 12.10。奇怪的是它会在12.04错误识别自己。有多个库吗?是否有可能ssh不使用最新的? - waTeim
我无法找到任何其他openssl二进制文件或加密库。其他人建议不同的是,在12.04 LTS,Ubuntu将更改向后移植到1.0.1而不增加版本。虽然12.10不是LTS,所以Ubuntu使用最新版本而不是后端。 - Martijn


这些脚本中的任何一个都可以测试所有服务,还是仅测试它们 HTTPS据我所知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

资源:

还有这些工具:


2
2018-04-09 11:43





对于Ubuntu,您可以使用:

aptitude show libssl1.0.0 | grep Version

并与之比较 http://www.ubuntu.com/usn/usn-2165-1/。重新启动(!!!)后,您可以查看 http://possible.lv/tools/hb


0
2018-04-08 11:14





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

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


0
2017-10-19 01:57