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 ~]# 
1
  • Why not use the python tester?
    – Ángel
    Aug 25, 2014 at 22:11

3 Answers 3

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.

5
  • Same error unfortunately Aug 25, 2014 at 20:06
  • Trying which options?
    – raz
    Aug 25, 2014 at 20:10
  • 1
    btw. isn't the flag in the link -lssl3? I can't find -lss3 anywhere. And -lssl3 is already used by OP.
    – user10008
    Aug 25, 2014 at 20:50
  • You're right, I could have sworn I double checked for the -lss3 option but it is used by the OP. I'm still unsure if the OP has checked the header file as was suggested in the 3rd link I have. I'm not sure what comments might be included here.
    – raz
    Aug 26, 2014 at 0:04
  • "You can also try statically linking OpenSSL into your build" - that's irrelevant.
    – jww
    Sep 17, 2014 at 1:58
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 <[email protected]> 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

You must log in to answer this question.

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