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?
3
-
1Generally speaking this can't be done, or at least is really hard, because this information is lost during the linking.– Karol BabiochApr 8, 2014 at 11:14
-
Rebuild the whole codebase to be on the safe side...– Deer HunterApr 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.– AugustoApr 8, 2014 at 12:56
Add a comment
|
1 Answer
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.
answered Apr 8, 2014 at 21:48
