6 ms·

How to reliably and portably check the OpenSSL version?

22 points by tsudot 13y ago

yesimahuman 13y ago
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.
- dfc 13y ago
  Or: dpkg -l libssl1.0.0 FYI: dpkg and apt-cache do not need to have elevated privileges to print the installed version.
- saurik 13y ago
  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 https://launchpad.net/ubuntu/+source/openssl/+changelog
agnokapathetic 13y ago
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
stormbrew 13y ago
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.
- ssafejava 13y ago
  What's the rationale for doing this, rather than simply using the package from upstream?
  - stormbrew 13y ago
    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.
  - jlgaddis 13y ago
    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.)
- saurik 13y ago
  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 https://launchpad.net/ubuntu/+source/openssl/+changelog
- RossM 13y ago
  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/ALAS-2014-320/ http://aws.amazon.com/amazon-linux-ami/security-bulletins/AL...
__alexs 13y ago
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.

22 points by tsudot 13y ago

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.

dfc 13y ago
Or: dpkg -l libssl1.0.0 FYI: dpkg and apt-cache do not need to have elevated privileges to print the installed version.
saurik 13y ago
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 https://launchpad.net/ubuntu/+source/openssl/+changelog

agnokapathetic 13y ago

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

stormbrew 13y ago

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.

ssafejava 13y ago
What's the rationale for doing this, rather than simply using the package from upstream?
- stormbrew 13y ago
  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.
- jlgaddis 13y ago
  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.)
saurik 13y ago
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 https://launchpad.net/ubuntu/+source/openssl/+changelog
RossM 13y ago
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/ALAS-2014-320/ http://aws.amazon.com/amazon-linux-ami/security-bulletins/AL...

__alexs 13y ago

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.