Solved [Solved] Still vulnerable to heartbleed

Hi everyone.

I'm currently using FreeBSD 10.0-RELEASE-p3 with jails. I'm using ezjail-admin, and all jails were 9.2 but I updated to 10.0. In the "www" jail I'm using nginx as a webserver, and I just discovered it is impacted by heartbleed. This is weird, I'm already up to date (host, ezjail, and ports), I don't know how to fix it.

Code:
root@www:~ # openssl version
OpenSSL 1.0.1e-freebsd 11 Feb 2013

Thanks for your help.
 
Re: Still vulnerable to heartbleed

I did but honestly I'm not sure everything is okay. For example, in the www jail, OpenSSL is 1.0.1e, so I think it is FreeBSD 10. But in /etc/rc.d I cannot find local_unbound there is still named. Anyway, ezjail-admin update does not find any updates:

Code:
root@HOST:~ # ezjail-admin update -u
Looking up update.FreeBSD.org mirrors... none found.
Fetching metadata signature for 10.0-RELEASE from update.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
Preparing to download files... done.

No updates needed to update system to 10.0-RELEASE-p3.
No updates are available to install.
Run '/usr/sbin/freebsd-update fetch' first.
 
Re: Still vulnerable to heartbleed

src386 said:
... In the "www" jail I'm using nginx as a webserver, and I just discovered it is impacted by heartbleed. ...

What let you come to this discovery? Did you run one of the various test tools pointing to your webserver?

src386 said:
Code:
root@www:~ # openssl version
OpenSSL 1.0.1e-freebsd 11 Feb 2013

Perhaps, your discovery is not exactly a discovery but an assumption based on the version number of your OpenSSL installation. In that case, your assumption is wrong as others pointed already out in recent messages in a variety of threads on these forums.
 
Re: Still vulnerable to heartbleed

The fix for the heartbleed bug has been back ported to OpenSSL 1.0.1e, see:
http://svnweb.freebsd.org/base?view=revision&revision=264267

After freebsd-update fetch and freebsd-update install, OpenSSL is still version 1.0.1e, albeit the TLS heartbeat buffer overflow issue has been fixed, see:
http://svnweb.freebsd.org/base/rele.../d1_both.c?r1=260405&r2=264267&pathrev=264267
http://svnweb.freebsd.org/base/rele...l/t1_lib.c?r1=259065&r2=264267&pathrev=264267

FreeBSD 10.0-RELEASE-p3 tells us, that the system's OpenSSL should have been fixed. If your nginx setup still suffers from the vulnerability, this means that the particular crypto library that is utilized by nginx is not the patched one.

I have no experience with nginx, however, may it be possible that the old libcrypto has been linked statically into nginx? In that case, you would need to rebuild nginx.

You could use the ldd command in order to find out what dynamic libraries the nginx daemon is using:
# ldd /path/to/the/nginx-http-daemon
Then check whether it is really running against /lib/libcrypto.so.7, because this is the only one which may have been replaced by freebsd-update install.

Perhaps, something went wrong with freebsd-update. You may want to check the respective files whether it contain the patches:
/usr/src/crypto/openssl/ssl/d1_both.c
/usr/src/crypto/openssl/ssl/t1_lib.c
 
Re: Still vulnerable to heartbleed

Did you recompile all ports linking against OpenSSL? You should (have).
 
Re: Still vulnerable to heartbleed

Hi, thanks.

@DutchDaemon: Yes I did, I ran: portmaster -af on each jail after upgrade. The nginx port should be linked to builtin OpenSSL (default option).

@obsigna:
Code:
# ldd /usr/local/sbin/nginx 
/usr/local/sbin/nginx:
	libcrypt.so.5 => /lib/libcrypt.so.5 (0x280e6000)
	libpcre.so.3 => /usr/local/lib/libpcre.so.3 (0x28109000)
	libssl.so.7 => /usr/lib/libssl.so.7 (0x28172000)
	libcrypto.so.7 => /lib/libcrypto.so.7 (0x281cc000)
	libz.so.6 => /lib/libz.so.6 (0x28357000)
	libc.so.7 => /lib/libc.so.7 (0x2836b000)
	libthr.so.3 => /lib/libthr.so.3 (0x284d5000)
Everything seems to be fine.
I do not have the sources set, so I can't check the .c files.

I can try to reset the nginx options and reinstall? Or use another SSL implementation?
 
Last edited by a moderator:
Re: Still vulnerable to heartbleed

1. Check the libcrypto binary:
  • ls -l /lib/libcrypto.so.7 -- the size should be 2001568
  • openssl dgst -sha256 < /lib/libcrypto.so.7 -- the SHA256 digest should be: d7e5d8e51a7a39e22017e727d1dd225bf03c3908e6b351bbd684b42e26be32a9

2. Check for the OpenSSL heartbeat BO vulnerability:
  • Download the perl script from this site: https://github.com/noxxi/p5-scripts/archive/master.zip
  • Unpack the .zip-archive and locate the file check-ssl-heartbleed.pl
  • On your FreeBSD box run openssl s_server -cert /usr/src/crypto/openssl/apps/server.pem
  • On any machine in the same network run the downloaded perl script pointing it to the FreeBSD box in question ./check-ssl-heartbleed.pl ip.ip.ip.ip:4433
  • Show us the output of the script.
 
Re: Still vulnerable to heartbleed

Thank you @obsigna.

Code:
root@www:~ # ls -l /lib/libcrypto.so.7 
-r--r--r--  1 root  wheel  1609112 May 24 12:49 /lib/libcrypto.so.7
Not good :\

Code:
root@www:~ # openssl dgst -sha256 < /lib/libcrypto.so.7 
(stdin)= 3906484ed142bd1ead57730ef2bcdc8dd54e76379c72d0ea83f5a4b8161f3031
Not good :\

On your FreeBSD box run openssl s_server -cert /usr/src/crypto/openssl/apps/server.pem
Sorry I do not have the src set, /usr/src is empty :\
Should I install the sources set?
 
Last edited by a moderator:
Re: Still vulnerable to heartbleed

obsigna said:
1. Check the libcrypto binary:
  • ls -l /lib/libcrypto.so.7 -- the size should be 2001568
  • openssl dgst -sha256 < /lib/libcrypto.so.7 -- the SHA256 digest should be: d7e5d8e51a7a39e22017e727d1dd225bf03c3908e6b351bbd684b42e26be32a9

This will vary by architecture and release.
 
Re: Still vulnerable to heartbleed

wblock@ said:
obsigna said:
1. Check the libcrypto binary:
  • ls -l /lib/libcrypto.so.7 -- the size should be 2001568
  • openssl dgst -sha256 < /lib/libcrypto.so.7 -- the SHA256 digest should be: d7e5d8e51a7a39e22017e727d1dd225bf03c3908e6b351bbd684b42e26be32a9

This will vary by architecture and release.

Yep, the OP said he is on FreeBSD 10.0-RELEASE-p3. However, I wrongly assumed, the architecture is amd64, but now I see, it seems to be i386:

ls -l /usr/lib32/libcrypto.so.7
size = 1609112

openssl dgst -sha256 < /usr/lib32/libcrypto.so.7
SHA256 digest = fa17a892b40d754bf440b3ca95330f1932cbfdcdb950bc0ec5ec72111de9f3cc

The size of my lib32/libcrypto.so.7 is the same as of the libcrypto.so.7 of the OP, however the digest still doesn't match.
 
Re: Still vulnerable to heartbleed

src386 said:
On your FreeBSD box run openssl s_server -cert /usr/src/crypto/openssl/apps/server.pem
Sorry I do not have the src set, /usr/src is empty :\
Should I install the sources set?

You may use any other valid certificate & private key.

If you got the certificate and the key combined into one file then issue:
openssl s_server -cert /path/to/the/server-cert+key.pem

If you kept the certificate and the key in different files then issue:
openssl s_server -cert /path/to/the/server.crt -key /path/to/the/server.key

PS: Show us the output of: uname -a. Mine is:
Code:
FreeBSD obsigna10 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:31:10 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64
 
Re: Still vulnerable to heartbleed

Code:
root@www:~ # uname -a
FreeBSD www 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:26:10 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

I managed to get server.pem from src.txz. In the www jail:
Code:
root@www:~ # openssl s_server -cert server.pem 
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
bad gethostbyaddr
ERROR
shutting down SSL
CONNECTION CLOSED
ACCEPT

On the remote host:
Code:
root@TARDIS:~ # ./check-ssl-heartbleed.pl 192.168.0.3:4433
...try to connect with version 0x303 w/o SNI
...ssl received type=22 ver=0x303 ht=0x2 size=70
...ssl received type=22 ver=0x303 ht=0xb size=499
...ssl received type=22 ver=0x303 ht=0xc size=137
...ssl received type=22 ver=0x303 ht=0xe size=0
...send heartbeat#1
no reply(eof) - probably not vulnerable

Looks like OpenSSL in my FreeBSD 10.0-p3 is not vulnerable. I don't understand why SSLabs says my nginx webserver is not safe.
 
Re: Still vulnerable to heartbleed

src386 said:
Code:
root@www:~ # uname -a
FreeBSD www 10.0-RELEASE-p3 FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:26:10 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
Your architecture is i386 while mine is amd64. This almost explains the differences of the libcrypto.so.7 binary.

src386 said:
On the remote host :
Code:
root@TARDIS:~ # ./check-ssl-heartbleed.pl 192.168.0.3:4433
...try to connect with version 0x303 w/o SNI
...ssl received type=22 ver=0x303 ht=0x2 size=70
...ssl received type=22 ver=0x303 ht=0xb size=499
...ssl received type=22 ver=0x303 ht=0xc size=137
...ssl received type=22 ver=0x303 ht=0xe size=0
...send heartbeat#1
no reply(eof) - probably not vulnerable
Looks like OpenSSL in my FreeBSD 10.0-p3 is not vulnerable...
I don't understand why sslabs says my nginx webserver is not safe.

For demonstration purposes, I ran the same against a none-patched FreeBSD 10.0-RELEASE(-p0) (actually the Live CD from January 2014):
Code:
./check-ssl-heartbleed.pl 192.168.0.11.:4433
...try to connect with version 0x303 w/o SNI
...ssl received type=22 ver=0x303 ht=0x2 size=70
...ssl received type=22 ver=0x303 ht=0xb size=1009
[0] /C=UK/O=OpenSSL Group/OU=FOR TESTING PURPOSES ONLY/CN=Test Server Cert | Dec  8 14:01:48 2011 GMT - Oct 16 14:01:48 2021 GMT
...ssl received type=22 ver=0x303 ht=0xc size=329
...ssl received type=22 ver=0x303 ht=0xe size=0
...send heartbeat#1
...ssl received type=24 ver=303 size=16384
BAD! got 16384 bytes back instead of 3 (vulnerable)
At the bottom line, check-ssl-heartbleed.pl is capable to identify a vulnerable system, and you may want to run this against your nginx https-service:
$ ./check-ssl-heartbleed.pl www.your-domain.com:443

I checked my installation with Qualys SSL Labs and it returned with:
This server is not vulnerable to the Heartbleed attack. (Experimental)
Qualys SSL Labs didn't like my self-signed certificate, however, that is another problem.

What exactly is the result of Qualys SSL Labs for your installation?
 
Re: Still vulnerable to heartbleed

Good news, I ran portmaster -af again, and now everything is okay :e no more heartbleed. I may have been confused when upgrading the system and performed portmaster too soon.
Thank you all!
 
Back
Top