Hi,

I am using OpenSSL for a project I am working on. I ran into a couple of
bugs and would like to report them here. I checked the latest release of
OpenSSL (version 0.9.4). The bugs seem to remain there. I also include
my fix to the bugs.

These bugs are actually independent of specific platforms. I am
enclosing the platform information anyway just in case the information
is helpful.

I would also like to thank the OpenSSL developement team for the great
job you guys have done to maintain the software and the mailing lists.
If you need more information about what I have reported, please feel
free to contact me.

Lidong


Bug Report:

Platform information:

openssl:
OpenSSL 0.9.4 09 Aug 1999
built on: Mon Aug  9 11:17:07 EDT 1999
platform: solaris-sparcv9-gcc
options:  bn(64,32) md2(int) rc4(ptr,char) des(idx,cisc,16,long)
idea(int) blowfish(ptr)
compiler: gcc -DTHREADS -D_REENTRANT -mcpu=ultrasparc -O3
-fomit-frame-pointer -Wall -DB_ENDIAN -DBN_DIV2W -DULTRASPARC -DMD5_ASM


./config -t output:
Operating system: sun4u-sun-solaris2
Configuring for solaris-sparcv9-gcc
/usr/local/bin/perl5 ./Configure solaris-sparcv9-gcc

Platform:
SunOS 5.6 sun4u sparc

Compiler:
gcc version 2.8.1


BUG1:

Symptom: If we run the provided s_server and s_client (in the apps
directory)
under the default SSL version, the client will wait for more inputs
after
receiving a renegotiation request from the server (sent by s_server when
we
enter "R" from stdin). If the server does not send any data through the
SSL
link after renegotiation, then the client blocks: it can neither read
from
stdin nor send any data out.

Reason: I traced the problem to ssl3_read_bytes, after renegotiation
(line 712
of s3_pkt.c), if the renegotiation is successful, the program will go
back to
"start:", which waits for more packets from the peer. I think this is
problematic. I don't see any requirement that force the server to send
more
data after renegotiation.

My fix: I added the following between Line 721 and 722 of s3_pkt.c:

                                s->rwstate=SSL_READING;
                                bio=SSL_get_rbio(s);
                                BIO_clear_retry_flags(bio);
                                BIO_set_retry_read(bio);
                                return(-1);

Now that part of the function is as follows:

                if (SSL_is_init_finished(s) &&
                        !(s->s3->flags &
SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS) &&
                        !s->s3->renegotiate)
                        {
                        ssl3_renegotiate(s);
                        if (ssl3_renegotiate_check(s))
                                {
                                n=s->handshake_func(s);
                                if (n < 0) return(n);
                                if (n == 0)
                                        {

SSLerr(SSL_F_SSL3_READ_BYTES,SSL_R_SSL_HANDSHAKE_FAILURE);
                                        return(-1);
                                        }
==>                             s->rwstate=SSL_READING;
==>                             bio=SSL_get_rbio(s);
==>                             BIO_clear_retry_flags(bio);
==>                             BIO_set_retry_read(bio);
==>                             return(-1);
                                }
                        }
                rr->length=0;
/* ZZZ */       goto start;
                }

It seems to take care of this problem. After renegotiation, SSL_read
reports
error "SSL_WANT_READ", which can be handled properly without blocking.

=========================================================
BUG2: memory problem in $(OPENSSL)/crypto/bio/b_sock.c:283

        j=strlen(a->h_name)+1;
        if ((ret->h_name=Malloc(j)) == NULL) goto err;
 ===>   memcpy((char *)ret->h_name,a->h_name,j+1);
        for (i=0; a->h_aliases[i] != NULL; i++)
                {
                j=strlen(a->h_aliases[i])+1;
                if ((ret->h_aliases[i]=Malloc(j)) == NULL) goto err;
 ===>           memcpy(ret->h_aliases[i],a->h_aliases[i],j+1);
                }
Comment: j+1 should be replaced by j. Note that only j bytes are
allocated
using "Malloc", and j has already included the trailing '\0' of the
string.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to