Thursday, April 17, 2014

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?


No comments:

Post a Comment

Thanks for your comment; communities are not built without you.

But note than comments on older posts usually go into a modertion queue. It keeps out a lot of blog spam. Weird links to Web sites hosting malware, marketing nonsense, etc.

I really want to be quick about approving comments in the moderation queue. When I think I won't manage that, I will turn moderation off, and sweep up the mess as soon as possible.

If you find comments that look like blog spam, they likely are. As always, be careful of what you click on. I may have had moderation off, and not yet swept up the mess.