I have just upgraded the openssl library on my Ubuntu 12.04 server to fix the heartbleed bug. Here's the output that I get for the "openssl version -a" command:

OpenSSL 1.0.0g 18 Jan 2012
built on: Fri Apr 11 09:20:16 UTC 2014
platform: linux-x86_64
options:  bn(64,64) rc4(8x,int) des(idx,cisc,16,int) idea(int) blowfish(idx) 
OPENSSLDIR: "/usr/local/ssl"

From what I understand, the "built on" date should be after 07 Apr, 2014, which seems to be the case here. I restarted Apache after doing these changes, but I still see that my website is vulnerable to the Heartbleed bug.

Am I missing something here?

I upgraded the ssl library by downloading the latest source code and compiling/installing the same.

[Update] After Stephan's comments below, I directly upgraded the openssl using apt-get. I also updated my PATH to point to the newly upgraded openssl lib.

Here is what I see when I do "openssl version -a"

OpenSSL 1.0.1 14 Mar 2012
built on: Mon Apr  7 20:33:29 UTC 2014
platform: debian-amd64
options:  bn(64,64) rc4(8x,int) des(idx,cisc,16,int) blowfish(idx) 
compiler: cc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_NO_TLS1_2_CLIENT -DOPENSSL_MAX_TLS1_2_CIPHER_LENGTH=50 -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

As per the "built on", the lib was updated to the latest Apr 7 patch. However, my website still shows vulnerable to heartbleed.

Kindly help !

  • 2
    Why would you install from source? You should never do that unless there is an express requirement for some functionality the Ubuntu package doesn't provide. In this case, patched versions of OpenSSL and libssl were released within hours of the initial announcement. – EEAA May 1 '14 at 3:49
  • Finally....restarting Apache did the job....thanks everyone for the help ! – Kapil Kaushik May 1 '14 at 11:10
  • @EEAA, if more people would build from source and look at the source, then we wouldn't have this bug at all or at least not that seriously. – Sebastian Godelet May 1 '14 at 12:36
  • @SebastianGodelet - That it patently false. Sure, sysadmins who are very diligent might manage to keep their systems more up-to-date with tarball builds. However, the vast majority of admins would install once and then not want to go through the pain of the source install with each release. Distro binary packages are far superior in nearly every way for a very high percentage of use cases. Additionally, what percentage of linux admins do you think have the skill to read the OpenSSL source code and understand what it means? – EEAA May 1 '14 at 13:28
  • I was more focusing on developers. Just saying, one of the strength of open source is that people do look at the source from time to time. – Sebastian Godelet May 1 '14 at 13:42

The easiest and fastest way to protect yourself from Heartbleed is to update OpenSSL from the binary packages provided by the vendor. Don't compile from source unless you know what you are doing, or want to spend much more time learning. Compiling from source is more challenging and a waste of time if all you need to do is update software. It can be educational and enlightening.

OpenSSL 1.0.0g 18 Jan 2012
built on: Fri Apr 11 09:20:16 UTC 2014

Something is not right here. You want 1.0.1g not 1.0.0g. But Heartbleed is only a problem in OpenSSL 1.0.1 and 1.0.2. OpenSSL 1.0.0 was not vulnerable. Did you download old source files? Note that Ubuntu doesn't always accurately report the OpenSSL version, and you need to update libssl as well.

From what I understand, the "built on" date should be after 07 Apr, 2014, which seems to be the case here

No, look again. Your "built on" date is "Apr 11 09:20:16 UTC 2014". Is that when you compiled this source?

Note that if you build from source, you need to apply the correct flags. Read the security notice at http://www.openssl.org/news/secadv_20140407.txt

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

  • Hi Stefan...thanks for your comments. As I understand...I shouldn't have compiled from source.....but now that I have already done it...what do you think is the solution here? Should I re-compile the source code with the " -DOPENSSL_NO_HEARTBEATS" option and install it again? – Kapil Kaushik May 1 '14 at 5:19
  • 2
    Try to uninstall from source using make uninstall. Seek help here askubuntu.com/questions/87111/… – Stefan Lasiewski May 1 '14 at 7:18
  • "make uninstall" doesn't work....but I upgraded the openssl with "apt-get"....and pointed my PATH variable to it....since my source code lib was installed in a different directory...I was hoping this to work...but it didn't ! – Kapil Kaushik May 1 '14 at 8:59
  • 1
    Check to see if processes are still running in memory with the old libraries using grep 'libssl.*(deleted)' /proc/*/maps. If they are, you'll need to restart the processes that are using the old libraries. Rebooting the host is the easiest way to ensure that nothing is using the old libraries. See askubuntu.com/questions/444702/… – Stefan Lasiewski May 1 '14 at 15:37

Because you did not remove the vulnerable version of OpenSSL it is still on the system. Your new installation did not replace the files, but added new ones. Because the existing applications were linked against the old library the might continue to use it. So better upgrade your system the usual way, because fixed libraries are available for it.

  • 2
    And REBOOT. Otherwise running processes can still be using the old version in memory. – Tonny May 1 '14 at 9:03
  • Thanks Steffen/Tonny for your comments too ! BTW....you need not necessarily reboot your system. Just restarting Apache does the job....but your comment certainly pointed me in the right direction! – Kapil Kaushik May 1 '14 at 11:08
  • 1
    @KapilKaushik: You need to restart, not only Apache, but any other service or program that could conceivably be using OpenSSL. For example, mail daemons (postfix/dovecot/etc). Unless you can be positive you've found all of them, a reboot is by far the safest option. – Nate Eldredge May 1 '14 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.