3

We have an AWS server running OpenVPN which was built using Ubuntu 13.10. After the announcement of the Heartbleed vulnerability, we updated the server. This morning, we upgraded the server to 14.04. The current output of "openssl version -a" is:

OpenSSL 1.0.1f 6 Jan 2014 
built on: Mon Apr  7 21:22:23 UTC 2014 
platform: debian-amd64 
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)  
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -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"

I verified the fact that the server is still vulnerable using the following:

:~$ openssl s_client -connect openvpn.example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe
TLS server extension "heartbeat" (id=15), len=1

Attempts to run "sudo apt-get install openssl" return that the current version is already installed. What are the best options to resolve this issue? Does it appear there was a problem during distribution upgrade; i.e. is the 14.04 OpenSSL package actually outside the danger range? Or is there a possible issue with the repository itself?

1

3 Answers 3

5

As @david6 pointed out, the version of OpenSSL might still appear to be a vulnerable version. This is because Ubuntu, as many other distros, backports security fixes rather than updating to a whole newer version of the software (and possibly picking up new features and their attendant bugs along the way). So, just because you're running a "vulnerable version" of OpenSSL doesn't mean you're running a vulnerable version of OpenSSL.

However, if the available Heartbleed audits indicate you're still vulnerable, you're still vulnerable.

What I think is going on is that you've updated the package, but you haven't restarted the services that use OpenSSL, so they are still holding on to the older version that they loaded at startup.

There are two easy ways to fix that:

  1. Reboot the server.

  2. Identify and restart the affected services. An easy way to do this is with, checkrestart from the debian-goodies package. It should identify the affected services and even tell you what init scripts will restart them:

    $ sudo apt-get install debian-goodies
    $ sudo checkrestart
    
0
0

You are right to be concerned.

However, to no longer be vulnerable to OpenSSL / Heartbleed on Ubuntu, you just need to be using an updated compile of the OpenSSL library.

The command openssl version -a should show that new date: 'built on: Mon Apr 7'

Actual examples:

(1.) Ubuntu 14.04 LTS (64bit, desktop) - upgraded from 13.10

OpenSSL 1.0.1f 6 Jan 2014
built on: Mon Apr  7 21:22:23 UTC 2014
platform: debian-amd64
  :

(2.) Ubuntu 14.04 LTS (64bit, desktop) - NEW install

OpenSSL 1.0.1f 6 Jan 2014
built on: Mon Apr  7 21:22:23 UTC 2014
platform: debian-amd64
  :

(3.) Ubuntu 12.04 LTS (64bit, server) - fully updated

OpenSSL 1.0.1 14 Mar 2012
built on: Mon Apr  7 20:33:29 UTC 2014
platform: debian-amd64
  :

NOTE:

  • Ubuntu maintainer have a lengthy testing cycle before they will 'replace' a library with a brand new version (with differing features). The simple fix for this bug was to either add bounds-checking logic (for the heartbeat function) or to compile with a flag (pragma) to exclude the heartbeat functionality entirely. These two options will not adversely impact any other applications or services.

  • If you had installed a version of OpenSSL v1.0.1 (or v1.0.2 beta) from source, or download a binary (for Ubuntu) from somewhere, then you would indeed be vulnerable unless you were using v1.0.1g (or the compile option had been used to remove 'heartbeat'). Only use trusted sources.

1
  • My concern is the fact that I have no way to verify the assertion. All outside facing tests I have run indicate this particular server is vulnerable, while three other Ubuntu machines report they are safe from Heartbleed. As additional data, filippo.io/Heartbleed reports the following: Here is some data we pulled from the server memory: (we put YELLOW SUBMARINE there, and it should not have come back) The other sites in question return that there are no issues. So, I'll modify the question to "why am I getting a false positive if there is no threat?"
    – user270607
    Apr 18, 2014 at 23:21
-1

Upgrade to the latest and you'll be okay if you are running on Ubuntu for CVE-2016-2107: see https://forums.openvpn.net/viewtopic.php?f=4&t=21699&p=62376#p62376

If you dpkg the current openvpn_as server you can see it's updated for openssl past the bug:

jonathan@Jonathan-Les-MacBook-Pro:~/Downloads/openvpn/usr/local/openvpn_as/lib/pkgconfig$ cat openssl.pc
prefix=/usr/local/openvpn_as
exec_prefix=$
{prefix}
libdir=${exec_prefix}/lib64
includedir=${prefix}
/include
Name: OpenSSL
Description: Secure Sockets Layer and cryptography libraries and tools
Version: 1.0.2h
Requires: libssl libcrypto

For CVE-2016-2107 in https://www.openssl.org/news/secadv/20160503.txt: "OpenSSL 1.0.2 users should upgrade to 1.0.2h"

We upgraded to the latest and are A-OK now

Not the answer you're looking for? Browse other questions tagged .