We're analysing issue at work and I wondering how to find out if there's any binary with a statically compiled version of openssl which includes this bug.

Would it be possible to find a fingerprint from the code which contains the bug?

  • 1
    Generally speaking this can't be done, or at least is really hard, because this information is lost during the linking. Apr 8, 2014 at 11:14
  • Rebuild the whole codebase to be on the safe side... Apr 8, 2014 at 12:47
  • @Karol Babioch I have the same understanding, that's why I was wondering if using some kind of fingerprint from the could would help it. Deer Hunter we don't compile many applications ourselves and the ones we do compile don't use openssl statically. The problem is 3rd party applications... and also the security mindful approach (aka paranoid) that a 3rd party application might be vulnerable, but the vendor doesn't even know about it.
    – Augusto
    Apr 8, 2014 at 12:56

1 Answer 1


In the OpenSSL code there are several string definitions related to the heartbeat feature:

./ssl/ssl_err.c:{ERR_FUNC(SSL_F_DTLS1_HEARTBEAT),       "DTLS1_HEARTBEAT"},
./ssl/ssl_err.c:{ERR_FUNC(SSL_F_TLS1_HEARTBEAT),        "SSL_F_TLS1_HEARTBEAT"},
./ssl/ssl_err.c:{ERR_REASON(SSL_R_TLS_HEARTBEAT_PEER_DOESNT_ACCEPT),"peer does not accept heartbearts"},
./ssl/ssl_err.c:{ERR_REASON(SSL_R_TLS_HEARTBEAT_PENDING) ,"heartbeat request already pending"},

So the chance is high the you'll find the string heartbeat (ignore case) in the statically compiled program.

You must log in to answer this question.

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