Heartbleed: The OpenSSL Libraries are What Matter

Much of what has been published in the security trade press assumes that recommending public vulnerability-checking tools, intended to be pointed at Web servers, is the way to go. It seems to me that that that take involves unwarranted assumptions. First off, many of the tools are buggy, or they are limitted to publicly-available servers.

I get that last bit: people want to know what their exposure is, and that reprsents progress.

However, OpenSSL is baked into many things. It is not all about Web sites, public-facing or otherwise. I don't like to put any sort of code on this blog, but in this case I am not going to make my point if I don't do a bit of command-line work. Let us take Fedora 19 as an example. It's a reasonable proxy for the forthcoming RHEL-7, and is of course RPM-based.

Let's do a test erase on openssl:
rpm -e --test openssl 
error: Failed dependencies:
        /usr/bin/openssl is needed by (installed) authconfig-6.2.6-3.fc19.1.x86_64

We need to get rid of that error message, if we are to feed this into 'wc -l' (wordcount, line mode), so we use 'grep -v' to ignore that line:

rpm -e --test openssl 2>&1 | grep -v 'error' | wc -l

1

Cool; only that one line pertaining to authconfig was counted. 

And here is the problem

Some people are replacing OpenSSL, without also replacing the library package. Hopefully, you have been able to follow along at a command prompt of your own. Before I get to the bad news, I need to tell you that this was performed on a Fedora 19 workstation. A server, built intelligently, will have far fewer dependencies (and I am long-term advocate of minimal systems), but this will still illustrate my point: the OpenSSL libraries are the priority item.

And now the bad news

Substituting only 'openssl-libs' for 'openssl', and repeating our line count, we find the badness.

rpm -e --test openssl-libs 2>&1 | grep -v 'error' | wc -l

256

I could yack about how to categorize the problems. That's an important topic, but is short of my immediate point, which is that openssl-libs is the more important of the two packages, and has received almost no mention in the security trade press. 

The next question is

How do I tell if I have upgraded everything?

There is no simple answer to that. Back-porting is an issue. The author of the controversial Hut3 Cardiac Arrest tool states, at http://cryptogasm.com/2014/04/hut3-cardiac-arrest-disclaimer/ that

"As always, the correct way to test for the vulnerability is to check the version of OpenSSL installed on the server in question. OpenSSL 1.0.1 through 1.0.1f are vulnerable."

That is not quite correct, in package-manager terms. Let's return to Fedora 19, and look through the package update logs, for our most important package:

grep openssl-libs /var/log/yum.log

Jan 11 08:41:00 Updated: 1:openssl-libs-1.0.1e-37.fc19.x86_64

Apr 09 13:33:53 Updated: 1:openssl-libs-1.0.1e-37.fc19.1.x86_64

Notice that the April 9 fix is still reported as version e. If we query the software directly, we see the following.

openssl version

OpenSSL 1.0.1e-fips 11 Feb 2013

Still reporting version e, though the fix was in place. RHEL-6 will react in a similar fashion. Analysis: another bogus report from some random security provider. That's nothing new.

There are means of inspected each system behind a corporate firewall. Yes, backports can be handled, and the reason for doing them in the first place does make a certain amount (all engineering decisions are trade-offs) of sense. It's just a bit much to go into in a single post. Those with short attention spans would be complaining that they didn't get a tl;dr version, expressed in 140 characters on Twitter.

But I'll leave ou with a final question or two 

Did your restart whatever running services use openssl-libs? Has everything been re-linked?