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 '14 at 11:14
  • Rebuild the whole codebase to be on the safe side... Apr 8 '14 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 '14 at 12:56

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.