Скомпилируйте тестер Heartbleed.c на CentOS 6.x

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.

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).

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

Это выглядит хорошо. -lsslэто подпрограммы OpenSSL SSL / TLS. -lcryptoэто криптографические процедуры OpenSSL.

Но я не уверен в этом -lssl3. Что это за библиотека?

heartbleed.c :(. text + 0x47d): неопределенная ссылка на `SSL_CTX_SRP_CTX_init '

Похоже, что ваша версия OpenSSL не поддерживает пароль безопасного удаленного доступа (SRP) Томаса Ву . Или он был скомпилирован без поддержки.

Согласно OpenSSL CHANGELOG, SRP был добавлен в OpenSSL 1.0.1:

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

Вы можете проверить, была ли библиотека OpenSSL построена без SRP, с помощью следующего.

Сначала найдите библиотеку OpenSSL SSL / TLS:

$ 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 ... 

Во-вторых, посмотрите, экспортируется ли символ:

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

В моем случае, SRP не доступен, так как библиотека Apple, по умолчанию так вниз уровня (версия 0.9.7).

У меня есть еще одна копия библиотеки (версия 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 

Моя версия 1.0.1i имеет рутину.

Иногда вы можете построить без SRP. Чтобы проверить, был ли OpenSSL настроен без SRP:

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

В случае выше, я настроил для SRP.

Вот как это выглядит, когда OpenSSL настроен без функции (я настраиваю без 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используется в двух местах. Чтобы это исправить, просто закомментируйте это.

Сначала строка 355:

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

Во-вторых, строка 499:

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

В связи с этим, авторы эксплойта, вероятно, могли бы следить за номером версии OpenSSL. Библиотека предоставляет OPENSSL_VERSION_NUMBER (3) только для такого рода вещей. Что-то вроде:

#if (OPENSSL_VERSION_NUMBER >= 0x10001000L) && !defined(OPENSSL_NO_SRP) SSL_CTX_SRP_CTX_init(c->sslContext); #endif