1

I have been looking for days now for a solution to this, basically I am trying to test my network for the heartbleed bug, but I am unable to compile the tester on CentOS 6.x, any ideas or suggestions are greatly appreciated...

Link to tester

http://www.exploit-db.com/download/32998

Error I am getting

[root@www ~]# gcc heartbleed.c -o heartbleed -lssl -lssl3 -lcrypto
/tmp/cc4cZa2B.o: In function `tls_bind':
heartbleed.c:(.text+0x47d): undefined reference to `SSL_CTX_SRP_CTX_init'
collect2: ld returned 1 exit status
[root@www ~]#
Jeffrey L. Roberts
  • 444
  • 2
  • 6
  • 25

3 Answers3

1

For CentOS it's suggested to add the -lss3 flag to your compile line. Supporting link.

You can also try statically linking OpenSSL into your build, from the same link as above. Replacing the location of your *.a files:

#!/bin/bash
# Emerge openssl with static-libs to obtain all the *.a
mkdir -p heartbleed.d
cd heartbleed.d
ar x /usr/lib/libssl.a
ar x /usr/lib/libcrypto.a
ar x /usr/lib/libgmp.a
ar x /usr/lib/libz.a
cd ..
gcc -o heartbleed heartbleed.d/*.o heartbleed.c -ldl

If you're on Debian (for completeness I know this question is in relation to CentOS 6.x) then you'll have this problem. Then this link might help you with your problem, it provides the below solution:

$ gcc heartbleed.c -o heartbleed -Wl,-Bstatic -lssl -Wl,-Bdynamic -lssl3 -lcrypto
$ uname -a
Linux xxxxx Debian 3.2.54-2 x86_64 GNU/Linux
$ ls -al heartbleed
-rwxr-xr-x 1 x x357603 Apr 11 23:20 heartbleed

This link is kinda confusing, it presents the exact problem in 2013 but just says that they updated the header for compiling. So maybe triple check the header file for comments?

Another solution to your problem might be to answer the following. What version of OpenSSL does your network run? Here's an exerpt from HeartBleed.com

What versions of the OpenSSL are affected?

Status of different versions:

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT vulnerable OpenSSL 1.0.0 branch is NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable

It was patched in OpenSSL version 1.0.1g: From the OpenSSL Security Advisory:

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

You can recompile older versions with that flag if you can't upgrade.

RoraΖ
  • 196
0

It seems that the missed function has been deactivated through the build options of your OpenSSL library. You can try manually compiling openssl.

As an alternative, you could use nmap (First check your current nmap version, you may have the heartbleed script already).

0

gcc heartbleed.c -o heartbleed -lssl -lssl3 -lcrypto

This looks OK. -lssl is OpenSSL's SSL/TLS routines. -lcrypto is OpenSSL's cryptography routines.

But I'm not sure about -lssl3. What library is that?

heartbleed.c:(.text+0x47d): undefined reference to `SSL_CTX_SRP_CTX_init'

It appears your version of OpenSSL does not support Thomas Wu's Secure Remote Password (SRP). Or it was compiled without support for it.

According to the OpenSSL CHANGELOG, SRP was added at OpenSSL 1.0.1:

  *) Add SRP support.
     [Tom Wu <tjw@cs.stanford.edu> and Ben Laurie]

You can verify the OpenSSL library was built without SRP with the following.

First, find the OpenSSL SSL/TLS library:

$ find /usr/ -iname libssl.*
/usr/lib/libssl.0.9.7.dylib
/usr/lib/libssl.0.9.8.dylib
/usr/lib/libssl.dylib
/usr/local/ssl/android-14/lib/libssl.a
/usr/local/ssl/android-14/lib/libssl.so
/usr/local/ssl/android-14/lib/libssl.so.1.0.0
/usr/local/ssl/android-18/lib/libssl.a
/usr/local/ssl/android-18/lib/libssl.so
/usr/local/ssl/android-18/lib/libssl.so.1.0.0
...

Second, see if the symbol is exported:

$ nm /usr/lib/libssl.0.9.7.dylib | grep SSL_CTX_SRP_CTX_init
$

In my case, SRP is not available because Apple's default library is so down level (version 0.9.7).

I have another copy of the library cribbed away (version 1.0.1i):

$ nm /usr/local/ssl/macosx-x64/lib/libssl.dylib | grep SSL_CTX_SRP_CTX_init
0000000000034920 T _SSL_CTX_SRP_CTX_init

My 1.0.1i version has the routine.

Sometimes, you can build without SRP. To check if OpenSSL was configured without SRP:

$ cat /usr/local/ssl/macosx-x64/include/openssl/opensslconf.h | grep -A 1 SRP
$

In the case above, I configured for SRP.

Here's what it looks like when OpenSSL is configured without a feature (I configure without SSLv2):

$ cat /usr//local/ssl/macosx-x64/include/openssl/opensslconf.h | grep -A 1 SSL2
#ifndef OPENSSL_NO_SSL2
# define OPENSSL_NO_SSL2
#endif
--
# if defined(OPENSSL_NO_SSL2) && !defined(NO_SSL2)
#  define NO_SSL2
# endif

SSL_CTX_SRP_CTX_init is used in two places. To fix this, just comment it out.

First, line 355:

 /* SSL_CTX_SRP_CTX_init(c->sslContext); */

Second, line 499:

 /* SSL_CTX_SRP_CTX_init(c->sslContext); */

Related, the authors of the exploit could probably guard on OpenSSL's version number. The library provides OPENSSL_VERSION_NUMBER(3) just for this sort of thing. Something like:

#if (OPENSSL_VERSION_NUMBER >= 0x10001000L) && !defined(OPENSSL_NO_SRP)
    SSL_CTX_SRP_CTX_init(c->sslContext);
#endif
jww
  • 12,722