[openssl.org #3115] s3_srvr.c out-of-bound dereference (minor bug)
Attached patch fixes out-of-bound reads or r[4].
Thanks
--- ssl/s3_srvr.c.old 2013-08-20 11:34:59.0 -0700
+++ ssl/s3_srvr.c 2013-08-20 11:34:59.0 -0700
@@ -1838,7 +1838,7 @@
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE,SSL_R_UNKNOWN_KEY_EXCHANGE_TYPE);
goto f_err;
}
- for (i=0; r[i] != NULL i4; i++)
+ for (i=0; i4 r[i] != NULL; i++)
{
nr[i]=BN_num_bytes(r[i]);
#ifndef OPENSSL_NO_SRP
@@ -1874,7 +1874,7 @@
d=(unsigned char *)s-init_buf-data;
p= (d[4]);
- for (i=0; r[i] != NULL i4; i++)
+ for (i=0; i4 r[i] != NULL; i++)
{
#ifndef OPENSSL_NO_SRP
if ((i == 2) (type SSL_kSRP))
Re: not fork-safe if pids wrap
Most other libraries I've seen handle this by saving the pid in a static variable, and then comparing the current pid to it. This has the advantage of not needing pthreads, and also of only adding the entropy to the child if it is actually needed (i. e. it doesn't exec after fork). We may have to do that, but we'll still want to always use the current PID so that we don't end up relying on any kind of random device actually being present (not all environments have that, so while we can try to reseed, we can't be sure that this will work). By the way, in case you wonder why OpenSSL doesn't try to detect forking at all, that's because the PID may be differ between threads running on the same memory. If I remember correctly, that was the case for Linux threads in the ancient times when this code was written: http://cvs.openssl.org/chngview?cn=1519 http://cvs.openssl.org/chngview?cn=1520 Bodo
UTF8 decoding, unneeded byte masking
In a_utf8.c, lines 85 and 86 (1.0.1e) :
...
if((*p 0x80) == 0) { // as this byte looks like :
0xxx
value = *p++ 0x7f; // this line could as well be
written : value = *p++;
...
If I don't miss something, it would seems clearer to me.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: not fork-safe if pids wrap
On Thu, Aug 22, 2013 at 4:50 AM, Bodo Moeller bmoel...@acm.org wrote: Most other libraries I've seen handle this by saving the pid in a static variable, and then comparing the current pid to it. This has the advantage of not needing pthreads, and also of only adding the entropy to the child if it is actually needed (i. e. it doesn't exec after fork). We may have to do that, but we'll still want to always use the current PID so that we don't end up relying on any kind of random device actually being present (not all environments have that, so while we can try to reseed, we can't be sure that this will work). (So we probably should use the current time in addition to the PID to get a general solution to the PID wrap-around problem even on systems where actual independent reseeding isn't possible.)
Re: not fork-safe if pids wrap
El jue 22 ago 2013 10:37:12 CLT, Bodo Moeller escribió: (So we probably should use the current time in addition to the PID to get a general solution to the PID wrap-around problem even on systems where actual independent reseeding isn't possible.) Or the processor time stamp counter (RDTSC in x86) that is slightly less predictable than the current time since it depends on local processor state and is not generally accessible to a non-local attacker. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: not fork-safe if pids wrap
(So we probably should use the current time in addition to the PID to get a general solution to the PID wrap-around problem even on systems where actual independent reseeding isn't possible.) The FIPS PRNG uses a combination of PID, a counter and a form of system timer for the DT vector which is used on every invocation (a requirement of the standard). Oh, good. (I guess it was before the NIST SP 800-90A deterministic random bit generator that we couldn't use PID at all in NIST mode?) Using the same inputs with the different PRNGs certainly would make sense.
23 Aug 2013 openssl dailies
Why can I not reach ftp.openssl.org or www.openssl.org ? -- Member - Liberal International This is doc...@nl2k.ab.ca Ici doc...@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism The world will happily agree whenever a church labels the Scriptures wrong.-anon __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
