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_r... On Thu, 2014-04-10 at 15:16 +0200, tpb-crypto@laposte.net wrote:
Message du 10/04/14 13:11 De : "Peter Malone"
A : "cypherpunks@cpunks.org" 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.