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.
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. Yes, I had noticed your post on FD. In my opinion you are right,
On Thu, Apr 10, 2014 at 12:40 PM, Peter Malone <peter@petermalone.org> wrote: the value that is compared can come from the outside. It would be the same problem that is discussed (also) here. Perhaps the solution might look like the same. https://trac.torproject.org/projects/tor/ticket/3122 thanks Best regards
Cheers, Peter.
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.
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.
participants (3)
-
Peter Malone -
tpb-crypto＠laposte.net -
yersinia