OpenSSL, HeartBleed And Ubuntu: The Version #’s Don’t Match.

I spent a few hours last night patching OpenSSL on my servers for this site, WatchMeCode, etc. It was a pain. The worst part about it, though, was not recompiling things and actually getting the servers patched. The worst part was all the confusion about version numbers. 



If you haven’t heard of it yet, you need to get yourself over to right now. Basically, if you’re using OpenSSL (and who isn’t?) then your servers are vulnerable to attack and having your SSL keys stolen. You need to fix this ASAP by updating your OpenSSL version, recompiling anything that is built against OpenSSL and re-issuing your SSL certificates with keys. 

Yeah, it’s a pain. But it’s necessary.

The Version Problem

The real problem I ran in to last night was version numbers, like I said.

When you look around the internet, you’ll see that everyone says to update OpenSSL to version 1.0.1g – note the “g” – this is the important bit. Everyone says that if you have anything below this letter, then you’re vulnerable. Of course my servers were vulnerable at v1.0.1c. 


I’m running Ubuntu for both and and when I updated my OpenSSL build, I didn’t get v1.0.1g installed. I ended up with v1.0.1e – and a full on panic attack following that. How am I supposed to get v1.0.1g when apt-get only gives me v1.0.1e?!

The Real Version Number

It turns out Ubuntu didn’t update the letter at the end of the version number, when they applied the patch for v1.0.1… or something like that. I’m still not 100% clear on this. But here’s what I do know:

If you are on Ubuntu and you follow all the right steps to update OpenSSL, you will end up with v1.0.1e – and that’s ok.

The thing that you need to check is the LibSSL version, which can be done like this:

The output I get on my servers is:

The important thing to note, here, is the “Version” number at line 8: 1.0.1e-3ubuntu1.2

According to the Ubuntu OpenSSL page, this is the version number that has the HeartBleed patch.

Get this version # on your Ubuntu servers, and you’re good to go.

Check The Patch

As Dan Tao points out in the comments below, this is a frustrating situation trying to figure out if you are safe or not. In the case of Heartbleed, there are tools the check the actual vulnerability and not just the version number checks, hoping you have the right version number. I used to check my servers and got back green reports saying I’m good to go, after doing the updates.

  • Dan Tao

    I’m sure there are legit reasons for this, but it’s pretty frustrating. I’ve been facing confusion over exactly the same problem in my safe_yaml gem, regarding a similarly serious vulnerability recently discovered in libyaml.nn vulnerability, same issue: the guidance is “Make sure you have libyaml >= 0.1.6”; but the OS has patched the vulnerability without updating the version.nnI guess it’s the lesser of two evils from their perspective. Doing a full version update would require more integration testing and could possibly break other parts of the system.nnSeems to me relying on version number to determine vulnerability to an exploit is maybe a bad proxy. A better system would be one where you could actually query the OS for “Is this system patched against CVE X?” and get a yes/no answer.

    • Derick Bailey

      agreed. in the case of heartbleed there is a check for it: i’ve verified my servers are ok with this tool. i’ll update the post to reference this.

  • Ahmed Azzabi

    Thank you for the blog post, yes indeed this is confusing and frustrating. By the way you said that you use ubuntu for this site and watchmecode are they on the same VM or you have separate Vms so you have to apply the same steps twice

  • rinatio

    They’ve backported the fix Debian also has fixed it in the 1.0.1e version