How to reliably and portably check the OpenSSL version? | Hacker News Reader

How to reliably and portably check the OpenSSL version?

serverfault.com

22 pointstsudot11 comments

The way to do this on Ubuntu is to run

  $ sudo apt-cache policy libssl1.0.0

You want to see version 1.0.1-4ubuntu5.12 which is the correct, patched version. Just updated two of my servers.

Or:

  dpkg -l libssl1.0.0

FYI: dpkg and apt-cache do not need to have elevated privileges to print the installed version.

Depending on the version of Ubuntu (you seem to be using precise, 12.04); for me (on saucy, 13.10), it is 1.0.1e-3ubuntu1.2. You can check the changelog entry for your version here, to verify that it has the heartbeat fix.

https://launchpad.net/ubuntu/+source/openssl/+changelog

Can't reply on SE due to lack of karma there, but I think the reason this is different on Ubuntu LTS is that what's on 12.04 is not technically 1.0.1g, but 1.0.1 with (all?) changes backported to 1.0.1 by the ubuntu security team for the LTS release. On my 14.04-beta install it says 1.0.1f before, and still 1.0.1f after upgrading in similar fashion.

Basically 1.0.1-4ubuntu-5.12 is the version you want on ubuntu 12.04 (or 1.0.1-1ubuntu2 for 14.04), but openssl version doesn't report that.

What's the rationale for doing this, rather than simply using the package from upstream?

In general, the rationale would be to avoid backporting risky changes into a long term support OS, since they could affect stability. In openssl's case I'm not sure to what degree they've done any kind of stability-affecting changes in the lettered-subversions, so I don't know how well this applies here.

Because they aren't actually releasing a package for 1.0.1g.

Remember that the idea for the LTS releases is that as little as possible is changed ("stable") over a period of several years ("long term"). Upgrading to new versions of packages with new bugs^Wfeatures has the very real possibility of "breaking" stable environments.

Instead of doing that, they simply incorporate the patch/fix into the version of the software that the release shipped with. They can't, then, call it 1.0.1g because, well, it's not -- it is, for example, 1.0.1c with this patch applied.

It's for that reason that you can't trust the version numbers on the packages themselves.

(Several years ago, I would get really pissed off at Nessus because it generate false positives by simply looking at the version numbers of installed packages. These were scans of RHEL boxes as part of PCI and it caused a lot of extra work. I've no idea if Nessus still does that or not but I'm sure other, similar software does the same thing.)

or 1.0.1e-3ubuntu1.2 for 13.10; you can use this website to look up specific versions for the fix.

https://launchpad.net/ubuntu/+source/openssl/+changelog

Amazon have done something similar with their packages - the vulnerable version 1.01e, package version 37.64 has been upgraded to 1.01e 37.66. I guess it's a version they've patched themselves.

http://aws.amazon.com/amazon-linux-ami/security-bulletins/AL...

You can't even reliably use the version number defined in openssl.h because RedHat decided that they will never change it ever again during RHEL 5. They just endlessly patch some ancient version of 0.9.8. Fortunately 0.9.8 isn't effected by this bug.

A quick way to check if a server supports the heartbeat extension (won't tell you if it's patched or not)

    echo | openssl s_client -tlsextdebug -connect host:443 | grep heartbeat
    TLS server extension "heartbeat" (id=15), len=1

Reply on news.ycombinator.com