Re: Futher debug of possible race condition in 0.9.6b/c
On Fri, Apr 12, 2002 at 11:38:34PM -0600, Dax Kelson wrote: > On Fri, 2002-04-12 at 22:30, Geoff Thorpe wrote: > > > > Can you get any log messages from the server as to "errors" it is reporting > > at the time these connections are being dumped that are *not* reported when > > the connections are going OK? It could be a race condition above the LDAP > > layer, or inside it (above the SSL layer) - and it might also turn out to be > > associated with the first connection/stream rather than the second. (Though > > knowing nothing about the application in question, it's difficult to know > > what the relationship between those two are - different threads?) Either way, > > it looks like the "decision" to break ties is made at the server, so that's > > probably where you should look to for clues as to why. > > I will see if I can dig something up. > > The server is OpenLDAP 2.0.22 running on NetBSD-1.5.2 mips. > NetBSD-1.5.2 seems to come with openssl 0.9.5a, OpenLDAP is linked > against that openssl. > > The clients are Red Hat Linux 7.2 boxes. I'm using nss_ldap and > pam_ldap to have my user database and authentication performed out of > LDAP. The clients have openssl 0.9.6b and I've also tried 0.9.7c. > > I'm doing starttls between the clients and server. > > When logging in nss_ldap makes the first LDAP over TLS connection to > verify my user exists, and then when I supply my password pam_ldap makes > the second LDAP over TLS to check my password. This second one is the > one that fails. > > I have about 20 clients that have ~500Mhz cpus and everything works > perfectly. On about 15 clients with 1700Mhz cpus, the second pam_ldap > connection fails *unless* I bog down the client machine. > > Another clue. When I turn off nss_ldap and have my user account listed > in /etc/passwd,/etc/group, but *still* use pam_ldap to get perform the > password checking out of the LDAP server, it works! Your ssldump output is missing the cleartext negotiation including the STARTTLS command (there is a switch to make ssldump also show this part). I however doubt it will lead us anywhere. The analysis so far pretty much shows, that the server is closing down the connection. I must admit that I did not work with OpenLDAP, yet. Is OpenLDAP a multithreaded application? It might be possible that they have a race condition that leads to problems when a new connection is coming in from some host, while the old connection is not yet considered closed... Anyway we would need the output and error messages from the LDAP server. The ssldump output indicates that a new connection is attempted all the time, so that there should be no problem with session resumption. 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]
Small bugs in v3 client hello parsing
Hi,
It seems that I've found two small bugs in OpenSSL (at least 0.9.6c
and the latest snapshot).
In ssl/s3_srvr.c function ssl3_get_client_hello, after the
last field (compression) has been parsed, there's a test:
/* TLS does not mind if there is extra stuff */
if (s->version == SSL3_VERSION)
{
if (p > (d+n))
{
/* wrong number of bytes,
* there could be more to follow */
al=SSL_AD_DECODE_ERROR;
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_LENGTH_MISMATCH);
goto f_err;
}
}
Here "d" points to the start of the message, "p" to the
current location, and "n" is the length of the frame.
There are actually two bugs: First, the test should of
course be "p < (d+n)".
Second, if "p > (d+n)" then we have read past the end of the packet
anyway so it is an error no matter which protocol version we have.
It seems that the memory buffer allocated is always large enough,
so this does not crash OpenSSL or anything like that, but it
causes OpenSSL to accept invalid hello packets.
Best regards,
Pasi
--
Pasi Eronen E-mail [EMAIL PROTECTED]
Nixu Oy Tel +358 50 5123499
Mäkelänkatu 91, 00610 Helsinki Fax +358 9 4781030
__
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
Small bugs in v3 client hello parsing
> It seems that I've found two small bugs in OpenSSL (at least 0.9.6c
> and the latest snapshot).
>
> In ssl/s3_srvr.c function ssl3_get_client_hello, after the
> last field (compression) has been parsed, there's a test:
>
> /* TLS does not mind if there is extra stuff */
> if (s->version == SSL3_VERSION)
> {
> if (p > (d+n))
> {
> /* wrong number of bytes,
>* there could be more to follow */
> al=SSL_AD_DECODE_ERROR;
> SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_LENGTH_MISMATCH);
> goto f_err;
> }
> }
>
> Here "d" points to the start of the message, "p" to the
> current location, and "n" is the length of the frame.
>
> There are actually two bugs: First, the test should of
> course be "p < (d+n)".
Thanks. This will be fixed.
> Second, if "p > (d+n)" then we have read past the end of the packet
> anyway [...]
A test is missing earlier in the code. This should fix all the problems:
Index: s3_srvr.c
===
RCS file: /usr/local/openssl/cvs/openssl/ssl/s3_srvr.c,v
retrieving revision 1.49.2.13
diff -u -u -r1.49.2.13 s3_srvr.c
--- s3_srvr.c 2002/01/14 23:42:38 1.49.2.13
+++ s3_srvr.c 2002/04/13 22:17:58
@@ -711,7 +711,7 @@
SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_NO_CIPHERS_SPECIFIED);
goto f_err;
}
- if ((i+p) > (d+n))
+ if ((p+i) >= (d+n))
{
/* not enough data */
al=SSL_AD_DECODE_ERROR;
@@ -768,6 +768,13 @@
/* compression */
i= *(p++);
+ if ((p+i) > (d+n))
+ {
+ /* not enough data */
+ al=SSL_AD_DECODE_ERROR;
+ SSLerr(SSL_F_SSL3_GET_CLIENT_HELLO,SSL_R_LENGTH_MISMATCH);
+ goto f_err;
+ }
q=p;
for (j=0; jversion == SSL3_VERSION)
{
- if (p > (d+n))
+ if (p < (d+n))
{
/* wrong number of bytes,
* there could be more to follow */
--
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]
