It's no longer implemented in OpenSSL, however some of the versions which were not vulnerable to Heartbleed are impacted.
Also the latest version of Ruby and Android implement it. https://android.googlesource.com/platform/external/openssl/+/android-4.4.2_r2/ssl/ssl_lib.c On Thu, 2014-04-10 at 15:16 +0200, [email protected] wrote: > > > Message du 10/04/14 13:11 > > De : "Peter Malone" > > > A : "[email protected]" > > Copie à : > > Objet : Two possible vulnerabilities in OpenSSL? > > > > > Hey there, > > > > I was auditing OpenSSL last night. I looked at several files and found > > the following: > > > > https://github.com/openssl/openssl/blob/master/ssl/t1_lib.c#L2893 > > /* Determine if we need to see RI. Strictly speaking if we want to > > * avoid an attack we should *always* see RI even on initial server > > * hello because the client doesn't see any renegotiation during an > > * attack. However this would mean we could not connect to any server > > * which doesn't support RI so for the immediate future tolerate RI > > * absence on initial connect only. > > */ > > > > Well that's awful coding. > > > > Unless I'm mistaken, the following memcmp is vulnerable to a remote > > timing attack. > > https://github.com/openssl/openssl/blob/master/ssl/ssl_lib.c#L1974 > > static int ssl_session_cmp(const SSL_SESSION *a,const SSL_SESSION *b) > > { > > if (a->ssl_version != b->ssl_version) > > return(1); > > if (a->session_id_length != b->session_id_length) > > return(1); > > return(memcmp(a->session_id,b->session_id,a->session_id_length)); > > } > > > > I posted both of these findings to the full disclosure list last night. > > I figured someone on this list might find it interesting as well. > > > > Cheers, > > Peter. > > > > > > Your best bet would be to make an automated exploit for proof-of-concept. If > it allows skiddies to prank systems, people will rush to correct it and your > name will be in the headlines for your 15 minutes of fame.
