5

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) 
compiler: gcc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--    noexecstack -m64 -DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM
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 !

Kapil Kaushik
  • 153
  • 5
  • 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 01 '14 at 03:49
  • Finally....restarting Apache did the job....thanks everyone for the help ! – Kapil Kaushik May 01 '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 01 '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 01 '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 01 '14 at 13:42
  • PATH doesn't seem to be the right thing to look at; PATH is used to find binaries but not libraries. – Nate Eldredge May 01 '14 at 15:09
  • Please see also http://serverfault.com/questions/591246/verify-openvpn-is-no-longer-vulnerable-to-heartbleed/591248#591248 – MikeyB May 01 '14 at 17:47

2 Answers2

13

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.

Community
  • 1
Stefan Lasiewski
  • 22,949
  • 38
  • 129
  • 184
  • 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 01 '14 at 05:19
  • 2
    Try to uninstall from source using `make uninstall`. Seek help here http://askubuntu.com/questions/87111/if-i-build-a-package-from-source-how-can-i-uninstall-or-remove-completely – Stefan Lasiewski May 01 '14 at 07: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 01 '14 at 08: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 http://askubuntu.com/questions/444702/how-to-patch-the-heartbleed-bug-cve-2014-0160-in-openssl – Stefan Lasiewski May 01 '14 at 15:37
3

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.

Steffen Ullrich
  • 12,227
  • 24
  • 37
  • 2
    And REBOOT. Otherwise running processes can still be using the old version in memory. – Tonny May 01 '14 at 09: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 01 '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 01 '14 at 15:08