88

I was looking at a reliable and portable way to check the OpenSSL version on GNU/Linux and other systems, so users can easily discover if they should upgrade their SSL because of the Heartbleed bug.

I thought it would be easy, but I quickly ran into a problem on Ubuntu 12.04 LTS with the latest OpenSSL 1.0.1g:

openssl version -a

I was expecting to see a full version, but instead I got this:

OpenSSL 1.0.1 14 Mar 2012
built on: Tue Jun  4 07:26:06 UTC 2013
platform: [...]

To my unpleasant surprise, the version letter doesn't show. No f, no g there, just "1.0.1" and that's it. The listed dates do not assist in discovering a (non-)vulnerable version either.

The difference between 1.0.1 (a-f) and 1.0.1g is crucial.

Questions:

  • What is a reliable way to check the version, preferably cross distro?
  • Why isn't the version letter showing in the first place? I was unable to test this on anything else but Ubuntu 12.04 LTS.

Others are reporting this behaviour as well. A few examples:

Some (distro-specific) suggestions rolling in:

  • Ubuntu and Debian: apt-cache policy openssl and apt-cache policy libssl1.0.0. Compare the version numbers to the packages here: http://www.ubuntu.com/usn/usn-2165-1/
  • Fedora 20: yum info openssl (thanks @znmeb on twitter) and yum info openssl-libs

Checking if a older version of OpenSSL is still resident:

It turns out that updating the OpenSSL package on Ubuntu and Debian isn't always enough. You should also update the libssl1.0.0 package, and -then- check if openssl version -a indicates built on: Mon Apr 7 20:33:29 UTC 2014.

7
  • 2
    at least be sure that the OpenSSL version you have isn't g because of the date it shows
    – ppp
    Apr 7, 2014 at 23:57
  • 3
    This works on CentOS [root@null~]# openssl version -a OpenSSL 1.0.1e-fips 11 Feb 2013
    – Jacob
    Apr 7, 2014 at 23:57
  • 1
    @PatoSáinz I've checked apt-cache policy openssl and it responded with: Installed: 1.0.1-4ubuntu5.12 which is the 1.0.1g just released by Ubuntu for 12.04 LTS. I logged out and back in. Is there anything else I could do to verify?
    – Martijn
    Apr 8, 2014 at 0:05
  • 1
    I'll point out, for that that don't know, in case it's helpful... Ubuntu 12.04 LTS shipped with OpenSSL 1.0.1 (vanilla). Apr 8, 2014 at 0:27
  • 1
    If that build date is accurate, you cannot have "release versioned" code more recent than 1.0.1e, since 1.0.1f came out in 2014 per the OpenSSL 1.0.1 release notes. Individual lines or sections may have been backported to your Ubuntu version prior to the official OpenSSL 1.0.1f release, of course. And the build date may be less that completely helpful. Apr 8, 2014 at 2:38

8 Answers 8

67

Based on the date displayed by your version of OpenSSL, it seems you are seeing the full version displayed there.

Open SSL 1.0.1 was released on March 14th, 2012. 1.0.1a was released on April 19th of 2012.

So, I'm going to go ahead and assert that openssl version -a is the proper, cross-distro way to display the full version of OpenSSL that's installed on the system. It seems to work for all the Linux distros I have access to, and is the method suggested in the help.ubuntu.com OpenSSL documentation, as well. Ubuntu LTS 12.04 shipped with vanilla OpenSSL v1.0.1, which is the version that looks like an abbreviated version, on account of not having a letter following it.

Having said that, it appears that there is a major bug in Ubuntu (or how they package OpenSSL), in that openssl version -a continues to return the original 1.0.1 version from March 14, 2012, regardless of whether or not OpenSSL has been upgraded to any of the newer versions. And, as with most things when it rains, it pours.

Ubuntu is not the only major distro in the habit of backporting updates into OpenSSL (or other packages), rater than relying on the upstream updates and version numbering that everyone recognizes. In the case of OpenSSL, where the letter version numbers represent only bug fix and security updates, this seems nearly incomprehensible, but I have been informed that this may be because of the FIPS-validated plugin major Linux distros ship packaged with OpenSSL. Because of requirements around revalidation that trigger due to any change, even changes that plug security holes, it is version-locked.

For example, on Debian, the fixed version displays a version number of 1.0.1e-2+deb7u5 instead of the upstream version of 1.0.1g.

As a result, at this time, there is no reliable, portable way to check SSL versions across Linux distributions, because they all use their own backported patches and updates with different version numbering schemes. You will have to look up the fixed version number for each different distribution of Linux you run, and check the installed OpenSSL version against that distribution's specific version numbering to determine if your servers are running a vulnerable version or not.

12
  • 3
    My install is a simple Ubuntu 12.04 LTS without anything I've compiled myself or downloaded from other sources than the Ubuntu repositories. If Ubuntu is distributing OpenSSL with abbreviated version numbers, then openssl version -a isn't a portable method (at least not portable to Ubuntu). I've checked apt-cache policy openssl and it responded with: Installed: 1.0.1-4ubuntu5.12 which is the 1.0.1g just released by Ubuntu for 12.04 LTS. I logged out and back in before checking.
    – Martijn
    Apr 8, 2014 at 0:11
  • 19
    HopelessN00b, there is nothing dubious about the policy of backporting fixes instead of bumping versions; it's a very good way of ensuring platform stability, which is highly-desirable in a server environment. Like any decision, it has consequences, which users need to be aware of; but just because it breaks the "I'm running foo x.y.z therefore I am/amn't vulnerable to the latest exploit" line of reasoning, that doesn't make it a bad thing.
    – MadHatter
    Apr 8, 2014 at 9:16
  • 10
    @towo Version numbers exist for a reason. If we're just gonna chuck the upstream version numbers out the window because "enterprisey," or whatever, why bother with version numbers at all? May as well just start naming all our stuff with alliterations. We can call the vulnerable OpenSSL versions Holy Heartbleed and the fixed ones Cunning Coagulant. Apr 8, 2014 at 13:36
  • 7
    @HopelessN00b I think you're getting caught up on the "this was fixed in version X.Y.Z" trap, they don't follow the version numbers because all that's getting imported into the latest version are bug and security fixes. If they bumped the version number, you'd also expect the additional functionality.. "I have OpenSSL v X.Y.Z, why don't I have ECDHA???? ..etc". It makes sense when you understand that it's only bugfixes.
    – NickW
    Apr 8, 2014 at 14:54
  • 13
    @NickW @Jubal @MadHatter the thing with OpenSSL, though, is that: 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. So, nothing is gained abandoning the upstream versioning scheme; backporting the updates is essentially the same as using the updated version, since the update only includes security and bug fixes anyway. What it does do is confuse things and leave us with no way to portably check OpenSSL version across Linux distros. Apr 8, 2014 at 22:13
18

If you want something truly cross-platform, check for the vulnerability itself rather than relying on version numbers.

You might have code that reports a version number that is known to be vulnerable, but the actual code is not vulnerable. And the reverse -- silently vulnerable code -- could be even worse!

Many vendors who bundle open-source products like OpenSSL and OpenSSH will selectively retrofit urgent fixes to an older version of code, in order to maintain API stability and predictability. This is especially true for "long-term release" and appliance platforms.

But vendors who do this silently (without adding their own version string suffix) run the risk of triggering false positives in vulnerability scanners (and confusing users). So to make this transparent and verifiable, some vendors append their own strings to the major package version. Both Debian (OpenSSL) and FreeBSD (in OpenSSH, via the VersionAddendum sshd_config directive) sometimes do this.

Vendors who don't do this are probably doing so to minimize the chance of breakage due to the many direct and indirect ways that other programs check version numbers.

So it can look like this:

$ 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

... even though it's been patched:

$ 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

With things like this in play, you're better off if you don't trust the version number.

2
  • It's clear that checking versions isn't as easy and transparant as I hoped it would be. Checking for the vulnerability is cross-platform, but also more difficult to do: you must have a reliable PoC or test handy for the particular vulnerable software service you're running. In this case it all started out with a PoC for Apache and nginx. What if I was only using SMTP with SSL at that moment, and I wanted to check if I'm vulnerable? Eventually we'll have tests for most services, but it may take a while.
    – Martijn
    Apr 9, 2014 at 8:30
  • Martijn, that's a fair point. When a test is not available, secondary methods (like tracking down the checksum for the affected binaries on your target systems) are less optimal, but might be good enough to get the job done ... and then move on to the next fire. :-) Apr 9, 2014 at 13:49
14

Unfortunately, I'm not sure there is a cross-platform way of doing this. As I discuss in a blog posting, the version of OpenSSL displayed on Ubuntu 12.04 REMAINS 1.0.1 after upgrading to a fixed version.

For Ubuntu 12.04 ONLY, you can tell if you've been updated if all of the below are true:

  1. dpkg -s openssl | grep Version shows version 1.0.1-4ubuntu5.12 or later.
  2. dpkg -s libssl1.0.0 | grep Version shows version 1.0.1-4ubuntu5.12 or later.
  3. openssl version -a shows a "built on" date of April 7, 2014 or later.

Thanks to @danny for the additional info.

4
  • 2
    Ok, in that case I must add that package version 1.0.1-4ubuntu5.12 is ONLY for Ubuntu 12.04 LTS. If you're on Ubuntu 12.10 you should see at least version 1.0.1c-3ubuntu2.7 and if you're on 13.10 then it should be at least version 1.0.1e-3ubuntu1.2, according to source: ubuntu.com/usn/usn-2165-1
    – Martijn
    Apr 8, 2014 at 7:51
  • 1
    This is unfortunately insufficient. You must also upgrade libssl1.0.0 explicitly on ubuntu. If you're seeing a built on date before April 7 2014 even if openssl is version looks correct (1.0.1-4ubuntu5.12 for Ubuntu 12.04) you are probably still vulnerable.
    – danny
    Apr 8, 2014 at 12:04
  • @danny You just saved me SO much work. I was trying to figure out why the build date was right on some 12.04 systems and wrong on others. You're a lifesaver!
    – Schof
    Apr 8, 2014 at 15:29
  • openssl version -a might not need the build date of April 7, because the fix is being backported to the older releases. Apr 10, 2014 at 22:06
4

Give the following a try. It will extract all the strings from the crypto library that ssh is linked against. It produces more than one line of output, but if necessary could be converted to 1 line.

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

produces

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

e.g. on Gentoo before emerge

[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

the above command results in

...
OpenSSL 1.0.1c 10 May 2012

after

...
OpenSSL 1.0.1f 6 Jan 2014

Ouch, still no g.

3
  • 3
    I thought you were very close to providing a good solution, but unfortunately this doesn't work for the crypto library on Ubuntu 12.04 LTS. It displays all the strings with version [...] part of OpenSSL 1.0.1 14 Mar 2012, the same way as openssl version -a does. This is a trick that may work in other cases though!
    – Martijn
    Apr 8, 2014 at 15:14
  • @Martijn Well that's unfortunate, but it does work on ubuntu 12.10. Strange that it would it mis-identify itself on 12.04. Are there multiple libs? Is it possible ssh does not use the most up-to-date?
    – waTeim
    Apr 8, 2014 at 15:59
  • I was unable to find any other openssl binaries or crypto libraries. It is suggested by others that the difference is that, on 12.04 LTS, Ubuntu is backporting the changes to 1.0.1 without upping the version. While 12.10 isn't an LTS and so Ubuntu uses the latest version there instead of a backport.
    – Martijn
    Apr 8, 2014 at 16:14
2

Do any of these scripts test all services, or do they only test HTTPS? AFAIK, PostgreSQL is vulnerable, but that's only a rumor until an in-the-wild attack surfaces.

There is a metasploit script available for use.

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

You can type this (tested with GnuWin32 OpenSSL binary version 1.0.1.6, dated 2014-01-14), or just use the script in the comment below this one. It's more accurate and simpler!

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

Once connected type B and you'll see on a vulnerable host and you won't be disconnected:

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

You will get a heartbeat response that looks similar to this one.

On a patched host, you will see a response similar to below and you'll be disconnected:

Enter 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   [email protected]...
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

Source:

There's also these tools:

0

For Ubuntu you can use:

aptitude show libssl1.0.0 | grep Version

And compare with http://www.ubuntu.com/usn/usn-2165-1/. After a reboot (!!!) you can check with http://possible.lv/tools/hb.

0

You'd better upgrade to latest OpenSSL OpenSSL 1.0.1j.

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

0

I found this script in devcentral:

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

Replace example.com with the name or IP address of the server you want to check.

Will return "safe" if your server is okay or "server extension "heartbeat" (id=15)" if not.

This doesn't rely on the version number, but on listing the server extension that causes the issue, so it should be immune to the library version shenanigans.

The machine you are running openssl s_client on must be using OpenSSL 1.0.1 or later in order for this to work.

9
  • 4
    Useful, but doesn't tell you if you have a version with the extension and the fix.
    – mattdm
    Apr 8, 2014 at 9:14
  • 1
    This is indeed a good way to check for the vulnerability and is what some scripts do. It does not actually require SSH access. Apr 9, 2014 at 3:38
  • 8
    BIG SCARY IMPORTANT WARNING - The machine you are running openssl s_client on MUST be using OpenSSL 1.0.1 or later in order for this to work. If you run this command on a machine with 0.9.8 or 1.0.0 IT WILL ALWAYS REPORT "Safe", even for vulnerable servers.
    – voretaq7
    Apr 9, 2014 at 5:52
  • Odd. I'm running a version of OpenSSL that is supposedly affected by this bug, yet that string doesn't appear in the output...
    – Michael
    Apr 9, 2014 at 17:30
  • @StefanLasiewski I updated my answer and removed the "need ssh" part
    – egarcia
    Apr 9, 2014 at 18:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .