[openssl.org #291] race condition in *get_cipher_by_char
s2_lib.c:ssl2_get_cipher_by_char
s3_lib.c:ssl3_get_cipher_by_char
has this code:
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL);
...[qsort and stuff]...
CRYPTO_w_unlock(CRYPTO_LOCK_SSL);
init=0;
}
There needs to be a if (init) after the lock is acquired to prevent the
static data from being trashed while another thread is using it.
Or, you can use an atomic set operation instead, if openssl has that
available:
if (atomic_set(init, 1) == 0) {
// do init stuff
patrick
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
I wrote that the next snapshots should solve the problem. Functions
SSLv23_client_method(), SSLv23_server_method(),
SSLv2_client_method(),SSLv2_server_method(),
SSLv3_client_method(),SSLv3_server_method(),
TLSv1_client_method(),TLSv1_server_method()
now use a lock.
Bodo,
Many thanks for putting in a lock. However, the race condition has not been
eliminated.
The functions now have:
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL_METHOD);
memcpy((char *)SSLv3_client_data,(char *)sslv3_base_method(),
sizeof(SSL_METHOD));
SSLv3_client_data.ssl_connect=ssl3_connect;
SSLv3_client_data.get_ssl_method=ssl3_get_client_method;
init=0;
CRYPTO_w_unlock(CRYPTO_LOCK_SSL_METHOD);
}
Two threads can enter init, and stop at the lock. One thread will get the
lock, set up client_data, exit the lock, and start using the struct. Then,
the other thread will get the lock, and mangle client_data while the first
thread is using it.
To prevent this, init must be checked after the lock is entered in order to
prevent the client_data setup from happening twice. So, add:
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL_METHOD);
if (init)
{
}
CRYPTO_w_unlock(CRYPTO_LOCK_SSL_METHOD);
}
patrick
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
[PATCH] Adding Certicom licensing info
Greetings: Certicom has intellectual property rights relating to safe primes in DH and point compression in elliptic-curve cryptography. I ask that the following patches be implemented to inform people of these facts. Sincerely, john -- john o goyo [EMAIL PROTECTED] Certicom Research, Certicom Corp. 5520 Explorer Dr., 4th Floor Mississauga, Ontario, Canada L4W 5L1 -- Index: README === RCS file: /home2/johng/prj/cvs-openssl/openssl/README,v retrieving revision 1.44 diff -u -b -B -r1.44 README --- README 25 Jul 2002 11:19:58 - 1.44 +++ README 24 Sep 2002 16:09:36 - @@ -111,6 +111,14 @@ should be contacted if that algorithm is to be used; their web page is http://www.ascom.ch/. + Certicom has intellectual property rights relating to the use of safe primes + in the DH key-exchange, including US patent 5,933,504 and pending US + and non-US applications, and to the use of point compression in elliptic-curve + cryptography, including US patent 6,141,420 and pending US and non-US applications. + A license to these rights is available on reasonable and non-discriminatory + terms from Certicom. Please contact Certicom for information. + ([EMAIL PROTECTED]) + INSTALLATION Index: apps/dh.c === RCS file: /home2/johng/prj/cvs-openssl/openssl/apps/dh.c,v retrieving revision 1.21 diff -u -b -B -r1.21 dh.c --- apps/dh.c 22 Feb 2002 13:59:16 - 1.21 +++ apps/dh.c 23 Sep 2002 18:32:48 - @@ -55,6 +55,12 @@ * derivative of this code cannot be changed. i.e. this code cannot simply be * copied and put under another distribution licence * [including the GNU Public Licence.] + * + * Certicom has intellectual property rights relating to the use of safe + * primes in the DH key-exchange, including US patent 5,933,504 and + * pending US and non-US applications. A license to these rights is + * available on reasonable and non-discriminatory terms from Certicom. + * Please contact Certicom for information. (http://www.certicom.com) */ #ifndef OPENSSL_NO_DH Index: apps/dhparam.c === RCS file: /home2/johng/prj/cvs-openssl/openssl/apps/dhparam.c,v retrieving revision 1.23 diff -u -b -B -r1.23 dhparam.c --- apps/dhparam.c 6 Mar 2002 14:15:09 - 1.23 +++ apps/dhparam.c 24 Sep 2002 16:11:15 - @@ -107,6 +107,11 @@ * ([EMAIL PROTECTED]). This product includes software written by Tim * Hudson ([EMAIL PROTECTED]). * + * Certicom has intellectual property rights relating to the use of safe + * primes in the DH key-exchange, including US patent 5,933,504 and + * pending US and non-US applications. A license to these rights is + * available on reasonable and non-discriminatory terms from Certicom. + * Please contact Certicom for information. ([EMAIL PROTECTED]) */ #ifndef OPENSSL_NO_DH Index: crypto/dh/dh_gen.c === RCS file: /home2/johng/prj/cvs-openssl/openssl/crypto/dh/dh_gen.c,v retrieving revision 1.9 diff -u -b -B -r1.9 dh_gen.c --- crypto/dh/dh_gen.c 20 Mar 2002 16:04:04 - 1.9 +++ crypto/dh/dh_gen.c 24 Sep 2002 16:11:51 - @@ -81,6 +81,12 @@ * I've implemented the second simple method :-). * Since DH should be using a safe prime (both p and q are prime), * this generator function can take a very very long time to run. + * + * Certicom has intellectual property rights relating to the use of safe + * primes in the DH key-exchange, including US patent 5,933,504 and + * pending US and non-US applications. A license to these rights is + * available on reasonable and non-discriminatory terms from Certicom. + * Please contact Certicom for information. ([EMAIL PROTECTED]) */ /* Actually there is no reason to insist that 'generator' be a generator. * It's just as OK (and in some sense better) to use a generator of the __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
Yes, the if (test) lock() if (test) construct is very important (although I thought I saw a bug about JVM implementations getting this wrong). Anyone doing threads programming should read Andrew Birrell's 1989 tutorial. http://gatekeeper.dec.com/pub/DEC/SRC/research-reports/abstracts/src-rr-035.html FYI, Birrell invented RPC. /r$ __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Tue, Sep 24, 2002 at 03:47:14PM -0700, Patrick McCormick wrote:
Many thanks for putting in a lock. However, the race condition has not been
eliminated.
[...]init must be checked after the lock is entered in order to
prevent the client_data setup from happening twice. So, add:
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL_METHOD);
if (init)
{
}
CRYPTO_w_unlock(CRYPTO_LOCK_SSL_METHOD);
}
You are absolutely right, of course. I got similar constructs right
in the past, but I guess this time I was too busy with various other
things to really think about what I was writing ...
The next snapshot should really fix the problem.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Tue, Sep 24, 2002 at 03:47:14PM -0700, Patrick McCormick wrote:
Many thanks for putting in a lock. However, the race condition has not been
eliminated.
[...]init must be checked after the lock is entered in order to
prevent the client_data setup from happening twice. So, add:
if (init)
{
CRYPTO_w_lock(CRYPTO_LOCK_SSL_METHOD);
if (init)
{
}
CRYPTO_w_unlock(CRYPTO_LOCK_SSL_METHOD);
}
You are absolutely right, of course. I got similar constructs right
in the past, but I guess this time I was too busy with various other
things to really think about what I was writing ...
The next snapshot should really fix the problem.
--
Bodo Möller [EMAIL PROTECTED]
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Disabling the crypt() macro.
I get reports again that the crypt() macro gets in the way for some applications. I'm strongly thinking of disabling it entirely. Anyone against? If I don't hear any complaints about the thought before the weekend, I'll carry on with it, in 0.9.7 and 0.9.7-dev. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #291] race condition in *get_cipher_by_char
__ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: Disabling the crypt() macro.
0.9.7 caused massive havoc compiling kerberos 4 (and to some extent 5) when I integrated beta 3 into the freebsd tree. The crypt() macro was a minor annoyance. The bigger problem was the redefinition of the DES key state block (from array to struct). openbsd apparently has workarounds that include mods to evp.h but I haven't looked closely at them. I just took the brute force approach and wacked the kerberos code which is probably unnacceptable for long term maintenance. Sam - Original Message - From: Richard Levitte - VMS Whacker [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, September 25, 2002 8:15 AM Subject: Disabling the crypt() macro. I get reports again that the crypt() macro gets in the way for some applications. I'm strongly thinking of disabling it entirely. Anyone against? If I don't hear any complaints about the thought before the weekend, I'll carry on with it, in 0.9.7 and 0.9.7-dev. -- Richard Levitte \ Spannvägen 38, II \ [EMAIL PROTECTED] Redakteur@Stacken \ S-168 35 BROMMA \ T: +46-8-26 52 47 \ SWEDEN \ or +46-708-26 53 44 Procurator Odiosus Ex Infernis-- [EMAIL PROTECTED] Member of the OpenSSL development team: http://www.openssl.org/ Unsolicited commercial email is subject to an archival fee of $400. See http://www.stacken.kth.se/~levitte/mail/ for more info. __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #291] race condition in *get_cipher_by_char
On Wed, Sep 25, 2002 at 05:31:08PM +0200, Bodo Moeller via RT wrote: As usual, I really wrote that the bug will be fixed in the next snapshot (but RT2 still does not believe me :-). -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Adding Certicom licensing info
On Wed, Sep 25, 2002 at 08:49:47AM -0400, John O Goyo wrote: Certicom has intellectual property rights relating to safe primes in DH [...] + Certicom has intellectual property rights relating to the use of safe primes + in the DH key-exchange, including US patent 5,933,504 and pending US + and non-US applications, [...] Can you elaborate? US patent 5,933,504 was filed in 1997, and using safe primes for DH was not new back then. URL:http://groups.google.com/groups?selm=2odko3%24jsf%40qualcomm.comoutput=gplain From: [EMAIL PROTECTED] (Phil Karn) Newsgroups: sci.crypt Subject: Re: Searching for primes Date: 12 Apr 1994 08:05:23 GMT Organization: 843rd Bomb Wing, Burpelson AFB Lines: 18 Distribution: world Message-ID: 2odko3$[EMAIL PROTECTED] References: [EMAIL PROTECTED] 2numd7$[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] NNTP-Posting-Host: unix.ka9q.ampr.org I'm following this discussion with interest because I'm currently generating some prime moduli for use with Diffie-Hellman. (DH is now included in RSAREF, so I'm using it as the basis of an experimental IP security protocol). My understanding of the criteria for a DH modulus p is that both p and (p-1)/2 should be prime, i.e, p should be a strong prime. I know that strong primes are no longer thought to be required for RSA key generation, but I understand that they're still a good idea for DH, which depends on the discrete logarithm problem rather than factoring (see LaMacchia's and Odlyzko's 1991 paper on discrete logarithms, URL http://martigny.ai.mit.edu/~bal/field.ps). Is this still the current consensus? Phil -- Bodo Möller [EMAIL PROTECTED] PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [PATCH] Adding Certicom licensing info
John O Goyo wrote: Greetings: Certicom has intellectual property rights relating to safe primes in DH and point compression in elliptic-curve cryptography. Really? Has that been tested? I ask that the following patches be implemented to inform people of these facts. Why would we want to advertise Certicom's products in OpenSSL? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
You are absolutely right, of course. I got similar constructs right in the past, but I guess this time I was too busy with various other things to really think about what I was writing ... The next snapshot should really fix the problem. I looked at the changes in CVS and everything seems to be correct now. Thanks for fixing this so quickly. I was looking at some other code in the ssl directory, and the *_method functions in the *_meth.c files appear to use the same initialization idiom. I believe they need to be thread-protected also. I grepped for if (init), and it now appears twice in all files except for *_meth.c and ssl_err.c. I don't believe ssl_err needs to be threadsafe since there's a thread safety page (somewhere, openssl.org is real slow right now) that explicitly says to run the SSL_load_error_strings() before using openssl on multiple threads. patrick __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
ssltest.c
In 0.9.7-stable ssltest.c, lines 408 416 need terminating brackets. Chris Brook __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: ssltest.c
On Wed, Sep 25, 2002 at 03:43:09PM -0400, Chris Brook wrote: In 0.9.7-stable ssltest.c, lines 408 416 need terminating brackets. Chris Brook Thanks, fixed, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
[openssl.org #290] OpenSSL make problems
[[EMAIL PROTECTED] - Tue Sep 24 10:23:50 2002]: Hi, I am trying to install openssl on AIX using gcc GCC version - 2.95.3 20010315 (release) AIX version - 4.3.2.0 OpenSSL version - 0.9.7-dev The output of config -t is attached. The make is not sucessful. The following is the error reoprted : making all in apps... rm -f openssl gcc -o openssl -DMONOLITH -I.. -I../include -DOPENSSL_THREADS -DOPENSSL_NO_KRB5 -D _THREAD_SAFE -D_POSIX_SOURCE -D_XOPEN_SOURCE=500 -D_ALL_SOURCE -D_NO_BITFIEL DS -Daix -O3 -DAIX -DB_ENDIAN openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o spkac.o smime.o rand.o engine.o ocsp.o -L.. -lssl -L.. -lcrypto -lpthread BN_LLONG RC4_CHAR gcc: BN_LLONG: A file or directory in the path name does not exist. gcc: RC4_CHAR: A file or directory in the path name does not exist. make: 1254-004 The error code from the last command is 1. What could be the problem? To first state the obvious: the BN_LLONG and RC4_CHAR are preprocessor settings that should find there way into opensslconf.h during Configure. I don't see in how far they should show up behind -lpthread. This is strange anyway: in my incarnation of OpenSSL the settings for aix, and this includes the aix43-gcc target, there is no -lpthread found. Do you work with a vanilla 0.9.7 version??? Best regards, __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
On Mon, Sep 23, 2002 at 06:43:21PM +0200, Bodo Moeller wrote: On Mon, Sep 23, 2002 at 04:26:00PM +0200, Bodo Moeller via RT wrote: Somehow the RT2 system doesn't like the comments I enter at the website when resolving a ticket ... I am not yet sure (would need to do a test), but it seems that RT2 eats the last line that is not terminated by a newline. I just ate my Lutz from my usual Best regards,\nLutz. Fortunately, it did not eat up more important parts of the text... Best regards, Lutz -- Lutz Jaenicke [EMAIL PROTECTED] http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #262] bug: init race in SSLv3_client_method
You are absolutely right, of course. I got similar constructs right in the past, but I guess this time I was too busy with various other things to really think about what I was writing ... The next snapshot should really fix the problem. I looked at the changes in CVS and everything seems to be correct now. Thanks for fixing this so quickly. I was looking at some other code in the ssl directory, and the *_method functions in the *_meth.c files appear to use the same initialization idiom. I believe they need to be thread-protected also. I grepped for if (init), and it now appears twice in all files except for *_meth.c and ssl_err.c. I don't believe ssl_err needs to be threadsafe since there's a thread safety page (somewhere, openssl.org is real slow right now) that explicitly says to run the SSL_load_error_strings() before using openssl on multiple threads. patrick __ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
