Determine Effective Security Version when faced with Backpatching?

0

0

The Heartbleed bug has a lot of people asking how to check the version of an installed package. I'm included since I have not discovered a way.

Unfortunately, backpatching has made version checking nearly useless because the info remains at the downlevel. For example (from Fedora):

$ openssl version -a
OpenSSL 1.0.1e-fips 11 Feb 2013
built on: Tue Apr  8 00:29:11 UTC 2014
platform: linux-x86_64
options:  bn(64,64) md2(int) rc4(16x,int) des(idx,cisc,16,int) idea(int) ...
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT ...
OPENSSLDIR: "/etc/pki/tls"
engines:  dynamic 

And Yum and Apt-Get are no better because they do not provide an effective security version (from Fedora with Yum):

$ yum info openssl
Loaded plugins: langpacks, refresh-packagekit
Installed Packages
Name        : openssl
Arch        : x86_64
Epoch       : 1
Version     : 1.0.1e
Release     : 37.fc19.1
Size        : 1.5 M
Repo        : installed
From repo   : updates
Summary     : Utilities from the general purpose cryptography library with TLS
            : implementation
URL         : http://www.openssl.org/
License     : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications
            : between machines. OpenSSL includes a certificate management tool
            : and shared libraries which provide various cryptographic
            : algorithms and protocols.

And (from Ubuntu and Apt-Cache):

$ apt-cache showpkg openssl
Package: openssl
Versions: 
1.0.1e-3ubuntu1.2 (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_saucy-updates_main_binary-amd64_Packages) (/var/lib/apt/lists/security.ubuntu.com_ubuntu_dists_saucy-security_main_binary-amd64_Packages) (/var/lib/dpkg/status)
 Description Language: 
                 File: /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_saucy_main_binary-amd64_Packages
                  MD5: 977022bc5545601176b69704acc5df9b
 Description Language: en
                 File: /var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_saucy_main_i18n_Translation-en
                  MD5: 977022bc5545601176b69704acc5df9b

1.0.1e-3ubuntu1 (/var/lib/apt/lists/us.archive.ubuntu.com_ubuntu_dists_saucy_main_binary-amd64_Packages)
 ...
Provides: 
1.0.1e-3ubuntu1.2 - 
1.0.1e-3ubuntu1 - 

As can be seen above, there's no information available on the effective security version ("1.0.1g"). The only information provided is that OpenSSL is downlevel ("1.0.1e") and possibly vulnerable to the latest bug.

Backpatching and downlevel version numbers has got to be one of the dumbest security decisions in history. Its right up there with
(1) opportunistic encryption is bad, plain text is good (browsers), and
(2) using public information as a secret/challenge question.

How does one determine the effective security version of a package that has been backpatched when using Yum and Apt-Get? (This is a generalized question, and not particular to OpenSSL).

jww

Posted 2014-04-11T04:44:13.990

Reputation: 1

Backpatching and downlevel version numbers has got to be one of the dumbest security decisions in history - Right, so just go run the unstable branches... Surely you are completely happy with unplanned, arbitrary changes constantly happening at any random point in time. – Zoredache – 2014-04-11T07:32:32.677

@Zoredache - I'm talking about security engineering, and you're talking about usability. From a usability standpoint, how is running Nessus {daily|weekly|monthly} to ensure compliance during audits improve usability? The results I have observed is systems often becomes unstable. And why would someone need to go to unstable when packages like OpenSSL, libxml2, etc are stable and binary compatible? – jww – 2014-04-11T12:13:45.637

Answers

2

I use rpm -q openssl --changelog | head

From this you can check the security patches, and depending on your repository it can give you an accurate version (depending how well commented it was).

I prefer this rather than simply going on build date and assuming that it contains the latest security patch

Since you specifically asked about doing it from yum, first you need to install changelog yum install yum-changelog

Then run yum changelog openssl, or to view while/before updating, yum update openssl --changelog

Out of interest I did a quick search to see if there was any other way to do it, but all I found was someone like yourself who wanted an easy way to check the security version, and he wrote a shell script to do it for any package (linked below)

Blog entry

Shell script

apt-get also (aparently) has a changelog feature by running apt-get changelog openssl
(I say apparently, because I have not tested this myself - some sources quote using aptitude changelog <package> instead)

dpkg has a tool included with the dpkg-dev package called dpkg-parsechangelog
(Again, I have not used this myself so I don't know what results it would provide, but I would guess similar information)

Addendum: The only easy way I could find of resolving the problem of a changelog providing the CVE and not a specific version is with the use of a tool such as vFeed.
I haven't actually used this particular tool (there may be others), but it provides command-line access to functions such as
get_cve : basic CVE attributes (summary, published and modified dates)

If someone had the time or inclination, I'm sure a simple shell script could be written which will combine the extraction of CVE information from the changelog and feed it into a tool such as vFeed, giving you a one-liner answer to the the question "Does package-x contain the latest security patches?".
In fact, most of the work is probably already done in the shell script I linked to previously..

Tim

Posted 2014-04-11T04:44:13.990

Reputation: 146

Thanks Tim. Is there an equivalent for dpkg or apt-get? – jww – 2014-05-05T11:49:35.493

OK, thanks again Tim. I just tested it on a Fedora VM. The best I can seem to find is a comment like "pull in upstream patch for CVE-2014-0160". Sadly, no effective security version. Lack of, for example, "1.0.1g" means I have to go rummage for what CVE-2014-0160 means. – jww – 2014-05-06T03:59:08.270

Unfortunately the specific version seems to be dependent on who did the patch - for example, in the standard CentOS repository we get `Mon Apr 07 2014 Tom Mraz tmraz@redhat.com 1.0.1e-16.7

  • fix CVE-2014-0160 - information disclosure in TLS heartbeat extension`

Gives us version and details However on the Amazon repository we get `* Mon Apr 07 2014 Cristian Gafton gafton@amazon.com

  • add fixes from upstream 1.0.1f/g releases (CVE-2014-0160, fixes for CVE-2013-0169)`

No specific version noted

– Tim – 2014-05-07T06:00:17.907

1

The most reliable way I have found to check the effective status of openssl is to run openssl version -a and look at the built on field. This date, paired with official Ubuntu/Fedora security bullettins, will provide the information you are looking for.

And I somehow agree with you on the backpatching, I must say that it can be confusing.

user1301428

Posted 2014-04-11T04:44:13.990

Reputation: 2 985

Believe it or not, I'm neutral to back patching. The thing I can't stand is the lack of an effective security version. That makes it useless. All it would take is one additional field in the package info... – jww – 2014-05-01T12:11:23.793

@noloader I know, I agree. Perhaps you could send a request to implement it? – user1301428 – 2014-05-01T13:06:33.110